buffer 在读取优势没有 string明显，在写入和拼接的时候才能体现出优势

感觉项目的思路不错，跟 deno 的类似，最近我也在研究这方面的东西，不过代码拉不来启动不了，可以给个介绍嘛

1.为什么不选择rust？
rust 源码分发难度和编译速度相比go有点差，rust语法概念过于复杂，rust迭代过于频繁很多语法经常变动，不适合我这样没有C基础的
性能这个问题其实是个仁者见仁智者见智的问题。
2.为什么选择go？
因为go有go关键字，go和js python很像，go的性能不是很差，go可以提供二进制分发能力。
3.为什么不选择esbuild和swc另起灶炉？
swc很适合我去偷懒，可惜我们的目标可能有些许偏差，我想要的是具有源码分发和二进制可分发能力的语言，而rust目前看还是有欠缺，swc和esbuild很棒但是有些理念违背了我的想法，我想要完全摆脱node_model与node这个属于2010年这十年间的产物，走向完全可以实现自主分发的程序，就比如deno的**和go mod的**就很棒。
还有esbuild自身定位的问题，就是ast不标准化（不要跟我聊性能问题），这会导致它只能作为一个打包器，而不能作为一个ast服务向其他服务提供能力。

因为js和go完全不同

使用 mime.TypeByExtension 推断的Content-Type 可能会受到当前操作系统设置的影响而无法正常读取正确的Content-Type

I came across your espack tool in hopes of finding a way to install and bundle Javascript dependencies without relying on NodeJS or NPM.

Does your tool work?

go 的struct的与c相同所以如果要通过面向对象来实现 继承必然会有问题
而go中的interface 相较而言却十分方便实现

从JS babel-parser的代码到go parse可以看出

babel的代码完全面向对象
而go的代码其实是面向接口，所以我觉得应该吸收他们的优点后进行改造

现在解析的ast的逻辑我是参照babel实现的，因而就会发现，其实很多estree 在go的表达应该是interface{}

所以通过理解我们可以得出

go 的面向对象与js || java 而言是分离的

go 的interface 意味着：
单独声明super abs ... 等等class 到 interface
至于具体实物则为struct 而struct 则尽量不应该继承，而是通过struct 去实现 interface 从而达到泛型的目的

而至于1.18的泛型是否能简化每个struct的使用是可以后续考虑的
下面我写点带go味的代码

type Food interface {
	Tasty()
}

type Beef struct {
// Beef attr
}

func (b Beef) Tasty() {}

type Grass struct {
// Grass attr
}

func (g Grass) Tasty() {}

type Animal interface {
	Eat(f Food) bool
}

type Dog struct {
// Dog   attr
}

func (d Dog) Eat(f Food) bool {
	f.Tasty()
	switch f.(type) {
	case Grass:
		return false
	case Beef:
		return true
	default:
		return false
	}
}

type Rabbit struct {
}

func (d Rabbit) Eat(f Food) bool {
	f.Tasty()
	switch f.(type) {
	case Grass:
		return true
	case Beef:
		return false
	default:
		return false
	}
}

func main() {
	var animals []Animal
	animals = append(animals, Rabbit{})
	animals = append(animals, Dog{})
	for _, animal := range animals {
		fmt.Println(animal.Eat(Grass{}))
	}
}

而在js里我们可以这样写

const Grass = {
    kind: "Grass"
}
const Beef = {
    kind: "Beef"
}
// inteface like
class Animal {
    eat(food) {
        return false
    }
}
class Dog extends Animal {
    eat(food) {
        switch (food.kind) {
            case "Grass":
                return false
            case "Beef":
                return true
            default:
                return false
        }
    }
}
class Rabbit extends Animal {
    eat(food) {
        switch (food.kind) {
            case "Grass":
                return true
            case "Beef":
                return false
            default:
                return false
        }

    }
}

const animals = [new Rabbit(), new Dog()]
animals.forEach(animal => {
    console.log(animal.eat(Grass))
})

从这个代码来看go 和js 各有冗余，js虽然没有了类型，但是因此得通过对象属性声明类型，go有了类型，但是需要冗余的实现duck type ：）

不应该需要在内存条件下还需要新建文件夹

func (f fs) IsDir(path string) bool {
	s, err := os.Stat(path)
	if err != nil {
		return false
	}
	return s.IsDir()
}

路线图

重要的第一步

• Toy webpack
• react 成功运行 ~~

考察插件

• 参照 coredns 的插件逻辑 实现插件机制
• 多种方式暴露插件调用，grpc, .so, ipc

伪代码逻辑：

package xxxPlugin

import (
	"fmt"
	"github.com/seasonjs/espack/pkg/api/plugin"
)

func init() { plugin.Register("espack_plugin_corejs", NewPlugin) }
func NewPlugin(opt interface{}) *interface{} {
	fmt.Println("plugin is regist in espack")
	return nil
}

{
  "entry": {
    "main": "index.jsx"
  },
  "output": "dist",
  "plugins": [
    {
      "name": "espack_plugin_corejs",
      "option": {
        "xxx": "xxx",
        "others": "this is others option"
      }
    }
  ]
}

调研npm替代方案

• 调研npm代替方案 js.mod -> go mod like?

• 调研npm元数据api获取

• 调研unpack方式获取，不大可行，es module 太少（可能会成未来的答案,但是现在我选npm）

• 调研go解压tgz格式文件

• 调研go.mod 解析生成原理

• 获取元数据

• 解决循环依赖

• 根据js.mod依赖生成js.sum

• 根据package.json 生成js.mod

• 根据解析好的数据下载tarball

• 处理espack install 命令逻辑

• 处理单个包下载命令逻辑

• 增加更多go mod like && npm like && yarn like 命令

• 完全摆脱对node_model的依赖优先考虑 统一保存，为了兼容性需要增加一个转译的cache，将下载的非esm模块提前转义为esm

• 调研Import maps vs js.mod的可能性

• 调研 其他多包其他 vs js.work的可能性

调研esbuild ast语法析出方案

• 放弃通过esbuild 生成的方案
• 转变为通过改造github.com/tdewolff/parse 进行Lexer，并自行根据estree生成ast
• estree 数据结构定义
• Lexer 施工
• Parser 施工

需要消灭的问题

• 逐步解决代码中的TODO注释
• 补充测试，增加代码覆盖率
• 命名更符合go风格（x）,更加c-like(√)
• 内部代码调整
• 注释，文档国际化

移除gin框架，它build之后过于大了->切换到liteS（gin lite）

迁移之后，没有了冗余的以下依赖，应用程序大小缩小了5M~~

github.com/gin-contrib/sse v0.1.0
github.com/go-playground/validator/v10 v10.9.0
github.com/goccy/go-json v0.7.8
github.com/json-iterator/go v1.1.12
github.com/mattn/go-isatty v0.0.14
github.com/stretchr/testify v1.7.0
github.com/ugorji/go/codec v1.2.6
google.golang.org/protobuf v1.27.1
gopkg.in/yaml.v2 v2.4.0

• 完美运行起gin的lite版
• 移除过重依赖
• 内部日志改造
• 完全改造为适合从内存/静态文件夹获取的server

调研go 18的泛型和monorepo

https://go.googlesource.com/proposal/+/master/design/45713-workspace.md
1.现在的go的ast结构还是不让人满意
2.现在的项目层级太深了

支持p2p 发布与下载包功能

https://github.com/anacrolix/torrent

ts 语言特性兼容

• 支持所有的类型编程特性

css 特性

assest资源处理

eslint特性支持