不要直接用js啊，用ts的泛型的接口
这个问题我记得发过了，没人回复，估计bug多到根本忙不过来了
一个比较扎心的事实，内心失望不是别人或其它客观条件引起的,本质上是面对问题，自己无能为力。
如果按照你这么说，那中国几乎没有人是“有能为力”的，包括字节跳动
你也知道字节跳动有不好的地方，为什么能包容字节跳动，不能包容一个游戏引擎呢？不要老说失望失望，特别是新的一年,对不？说实话，我觉得Cocos Creator 更新很快，社区很活跃，技术解答也很及时，挺好，哪天真没有国产引擎了，老外不让用Unity了，那样就好了？我们可以反馈问题，但不要带情绪，尽量为社区多做贡献，而不是在社区散播负面的情绪，对不？建议可以改下标题，就事论事的说Bug。
我同意你的就事论事的观点，同理的，很难换位思考下，”内心失望不是别人或其它客观条件引起的,本质上是面对问题，自己无能为力”，你看你这句话，说到底你就是说使用cc的开发者没能力改底层源码，如果大伙都有这个能力，那还要cc官方做啥？专业的人做专业的事，而不是大伙都具备这个能力，可你的意思就是觉得人家没能力改，是人家没能力，我吐了。收起你的大义凛然好吧~_~？
还有你在评论的时候也别带情绪呀，既然你能包容cc，为什么不能包容一下开发者的不满情绪？
大过年的，你们不干活的么，年夜饭准备好了？春联贴好了？灯笼挂上去了？正月里走亲戚的礼物准备好了？小孩子的红包换好新钱了？
一大堆事不去做，逛什么论坛
az，遗留代码直接一刀切确实可能有一些兼容问题
做程序的本身压力就大, 行业也不怎么景气, 所以满屏的红字肯定很让人恼火. 就像斗牛一样.
冷静, 学会冷静, 理智, 心态很重要. 有时自己也欠缺好的心态.
我觉得就是Cocos这帮人姿态太低了，太友善，导致有些人动不动弄一句“失望了”“太烂了”“什么都不是”吓唬开发者们，我们用户也就做个小游戏，哪来那么多不满意
姿势的高低是由产品的质量决定的，而不是你想多高就多高，如果产品质量低，姿势还高，那不是作死？看看隔壁的几家国产，还有几个人用哟。。。。
注意一下社区环境，不要骂街，有缺点不能吐槽嘛？顺来逆受？说的人也希望引擎开发者越做做好，如果说的人潜意识就认为官方人员做不到他所说的要求他还会说嘛？没有人去做质检员，要么就是这个工程已经没法被挑剔，要么就是这个工程已经不值得被挑剔。我是个开发者我希望官方支持的东西越来越多，也节省开发时间。
这个问题其实存在一些误解，在 3.x 中已经不推荐使用 cc 全局变量了，在代码中都是通过自动导入的，比如
import { Sprite } from 'cc';
而在控制台中，大家自然以为可以用 cc.Sprite 实际上这里的 cc 在引擎中是一个 legacyCC 的全局变量，我们保留确实是为了照顾一些使用习惯。
而 Jare 贴的那段代码中是为了兼容 Cocos Creator 3D v1.x 而存在的 deprecation 代码，在这个版本中我们使用的是 SpriteComponent 命名。这点有些疏于考虑，确实兼容 Cocos Creator 2.x 的用户要更重要，所以我们会在之后版本把 legacyCC.SpriteComponent 改为 legacyCC.Sprite。这样需要兼容的开发者就可以用 cc.Sprite 来访问 Sprite 组件了，但这不是我们推荐的方式
如果开发者在模块选择中剔除 deprecated 代码的话，那么所有 SpriteComponent 的用法和直接访问 cc.Sprite 的用法都会失效。
所以在实际项目中，我们只有下面的推荐用法
// 代码中
import { Sprite } from 'cc'
node.getComponent(Sprite);
// 控制台（无法导入）
> node.getComponent('cc.Sprite');
遵循 TypeScript 的模块规范，不使用全局变量，只支持导入是我们在 3.x 经历的一个很艰难的用户迁移过程，很多用户不理解，不接受，但这确实是一个不会改变的技术方向决策，我们相信它会给引擎的模块组织和项目代码带来进步，所以请大家理解
可以考虑解决一下Node的问题，ts环境中本来就有Node，所以不手动去引入Node的话，默认的Node会出错
可以帮忙回答一下这个问题嘛？我看了好几个类似这样的问题 都没有人回答
补充：可以在 tsconfig.json 里面加入 lib:["ES2017"]，自动提示里就不再提示 WEB 的相关类了。
这样console，setTimeout等常用的都没有了，一些web的东西还是会用到