ts引入公共方法_公共项目中，我用JSDoc代替了TS（为什么不用TS ？）

公共模块，通常会被多个项目、不同的开发人员使用，所以开发公共模块时，你自己会用还不够，要让所有人都能很快的知道怎么去使用，这一点很关键。通常会从3个方面做到这点：

精心分割代码逻辑，遵循开闭原则；

变量名采用自解释性的标识符；

依赖完善的使用提示。

本篇文章就是教你如何在实现js模块时，做好完善的使用提示。

是否要用ts写公共项目？

补充于：2020年11月17日09:43:12

公共模块使用ts编写的最佳做法是：在发布前通常会先编译成js，以及生成对应的types声明(d.ts文件)，发布的源码只会包括这些js代码和types声明。

这样的话，就不会强迫业务项目也使用ts了，本节之前表达的观点“反对使用ts写公共模块”是错误的，当然 .vue文件这样的除外。

ts和JSDoc到底用哪个？

ts相对来说更严格，更严格的好处是可以更好的避免类型引起的潜在问题，坏处就是有时会给编码带来不便(比如它会强制你去声明每一个变量的类型，即使某些变量你不想声明类型时)，jsDoc则相反。

ts在编译成js时类型信息会丢失，但js文件比较纯净，类型信息的保留是借助类型声明文件.d.ts的。jsDoc本身就是js，类型信息是通过注释完美的保存下来(当然引入了额外的类型相关的注释)，无需借助额外的文件。

ts非常强大，提供了系列的配置方式来简化操作或增强/削弱类型相关的功能，但ts会引入额外的编译 导致项目稍重。

ts以及ts和vue的集成(国内市场vue老大)并不是每个人都会(国内感觉大多数都不会)；JSDoc更易于学习，编码风格不像ts那样有变化(非常大的变化)，更易于被团队成员接受。

经过一段时间的实践，我觉得两者在类型提示和校验方面都适应绝大部分场景，没有优劣之分，总体来说 ts更严格，更强大，JSDoc更灵活，更原生高效。

你的项目正常应该是打包成 umd包，并且和源码一起发布。因为：

umd包使用非常灵活，支持script标签隐式引用，amd，cmd，commonjs，esm引用，也是当前最流行的公共模块包。但umd包不能使用tree-shaking。

tree-shaking作为官方的项目优化方案，目前越来越流行，几乎已是必备的项目优化技术。tree-shaking是基于es module的，单纯的umd无法实现。

通常源码就是通过es module编写，所以将源码一起发布，不只是让使用者能够查看，还为了让使用者方便tree-shaking优化。

如果业务项目(这里指