会的
从 ts 普遍起来，很多开源库、个人或是公司的项目开始使用 ts
ts 确实给我们的项目带来的了很多好处，但是这些好处也是建立在正确使用 ts 上的
如果一个项目盲目的引入 ts，但不对其参与项目的人有一定的 ts 知识要求，那么这个项目只能是比不使用 ts 强那么一点点
代码格式是否规范、优雅、可读性强等方面，很小的原因是用了什么技术，大部分原因在与什么样的人写了代码。
现在大部分 npm 库有携带类型声明，这些类型声明可以在编辑器内敲代码时给予参数或类型的提示、编译时的检测可能的错误等
库的类型声明也确实给我们带来的很多好处
但有些较为复杂的 API 在使用时如不按照要求添加泛型，那么这个 API 的返回值或者是回调参数也不会进行对应的提示
在上一步中，我们就已经制造出很多不好的代码（或是我们已经少写了很多类型）
对于一个比较复杂业务，如果我们完成了一个功能后，上面那中不好的味道已经在不少地方出现，当我们尝试去解决这种问题时，会发现改动代码需要一定的时间和精力，还要深入到库的声明文件(.d.ts)中去查看对应 API 需要的类型。
对于 ts 有一定的理解和有 ts 开发的经验来说，或许可以避免上面的情况，对于一个团队来说，对于 ts 的理解和经验参差不齐，除非集中培训或在面试时就对此有较高的要求或者在 review 期间就对这些代码要求反工，否则这种问题只有在重构时解决甚至永远留在项目中。
现在很多人会声明类型就是会 ts 了，写个复杂点的接口(interface)都写不下去，直接 any 大法好。
这样的情况不少见，ts 虽然带来的好处很多，但是只会声明类型 + 大量使用 any就已经把大量好处给隔离了。
好比你只学会了 js 声明变量、函数等基础语法，闭包、事件循环、回调函数等这些概念你都没学，那你自然享受不到或是不能理解 js 带来的便捷和好处
这样的项目中引入 ts 就是弊大于利。
个人解决这个办法就是读 ts 的文档、读开源库的 ts 代码，团队就需要有经验的人出来对其他人培训，附加一些 demo 的联系，然后在接下来的项目中引入 ts。
ts 现在确实有很多自身的 bug 或者是 js 的遗留问题导致有些顺应自觉的方式和底层接口的一些冲突并不能很好的解决，这种情况是必然的，但对于项目的影响或许不会很大，大家平时也碰不到很多。
类型不知道咋写，any 数据结构太复杂，any 参数不知道是类型，any
any 可以说是没学好 ts 的避风港，简直万能
如有有这种情况，那么你就需要评估你项目是否值得用 ts 了 如果值得，你就要评估，开发人员是否有足够的事件来进行学习 ts，达到使用的最低要求。
否则，出的是 js 的坑，进的是 ts 的坑