关于hel-micro中声明文件讨论

[lzs246]

跑了下hel-micro的demo，发现，hel-micro的声明文件是通过remote，npm publish的方式，将声明文件发到npm，然后消费remote的方，在通过npm把remote下载下来，然后remote业务代码通过远程加载hel-json加载。

这样是能保证remote的js是最新的，但是不能保证业务方，拿到的remote的声明文件是最新的（除非每次发一次remote，就让所有消费方npm install remote，但这样感觉本末倒置了），请问后续有啥关于remote声明文件优化的方向吗？

如果是我哪弄错了，麻烦指点。

[lzs246]

可不可以将声明文件也给加到hel-json中呢

[fantasticsoul]

你好，类型文件可能会滞后，这个会提供一个插件解决，大概思路时，每次模块启动项目之前有个脚本去npm仓库拉一次最新的代码并和当前使用方node_modules里的类型代码做比较，有不一样的时候提示用户需要更新类型文件？

例如执行 npm run check_type

[fantasticsoul]

类型文件加入到hel-meta没有作用哈，因为vsc IDE 识别的类型文件入口是 package.json里的types字段的值，这个值会查找到 node_modules下的某个模块目录下的某个文件作为类型提示入口文件。

[fantasticsoul]

大多数时候，类型文件是稳定的但运行代码发生了变化，如果模块提供方发布了新功能，使用方肯定要拉最新的npm包获取最新的类型，如果使用方不关心新功能的话，其实对于已存在的代码调用来说就达到了无感知升级的效果了

[lzs246]

类型文件加入到hel-meta没有作用哈，因为vsc IDE 识别的类型文件入口是 package.json里的types字段的值，这个值会查找到 node_modules下的某个模块目录下的某个文件作为类型提示入口文件。

npm包的形式确实是这样；但是页面项目中应该xx.d.ts，这种IDE应该也能识别吧。

我团队解决模块联邦声明文件就是，remote构建时产生一个整的声明文件，然后上传。然后使用方在本地起项目时，会去拉取remote的声明文件，这样就解决remote声明文件一定是最新的。 但是这样也有问题，体积太大，导致解析速度慢。

但是适用于hel-micro的还是 上面讲的 npm run check_type

[fantasticsoul]

类型文件独立维护，package.json里 types值指向独立的类型文件， 然后 check_types自动把最新的类型文件下载到本地，让类型文件和源码文件也分离？

[lzs246]

感谢大佬指点

[fantasticsoul]

关闭此讨论