一直用2.x,最近才开始学习3.x,看到这样一条。感觉之前cc.xxx这样写挺方便的，现在每个脚本还要单独去引用模块，挺麻烦的。想知道这样的写法是有什么弊端么？自己的项目里面也参照这样的写法，定义了命名空间，通过xx.xxx访问一些方法和类。对ts也不是很精通，希望懂得大佬指点一二，如果不好得话也及时改正下自己的代码规范，感谢！
2赞
个人认为是负向优化，对老用户影响不大，因为都熟悉了api，新用户的感受完全没考虑到，使用组件都需要去看文档才能写代码
也可以试试 import * as cc from “cc”;
2赞
莫非现在还是全部的api都在一个包下？
按理说现在这么改是可以直接跳转看源码的…
感谢回复，感觉是个不错的办法，cc.写顺手了 
很简单，这样写，不会污染全局变量
主流是模块化
不污染全局命名空间
利于 tree shaking
那是不是意味着我项目中没有用到的模块，打包时会自动从引擎中剔除，不用像2.x一样手动剔除
有个问题想请教一下：
项目情况：
- CCC 2.1.2，项目是大厅+子游戏模式，都是独立工程。
- 通过修改引擎，能够通过大厅项目直接加载子游戏项目，运行良好。
- 有一套公共库，基于ts+namespace编译，cocos中以插件引入。开发时游戏和大厅工程都用到这个库。
- 构建后，游戏剔除该库，和大厅共用该库。
- 该公共库，会直接访问cc中的一些功能。
现在3.x 改用了模块，遇到了一些问题:
1， 如果该库仍然以namespace模式编写，则无法直接访问cc，因为namespace中不能访问模块。
2，如果把该库改为模块的形式，则在游戏项目中，构建后，如何把这块代码剔除掉呢? (想过把它放在一个独立的bundle里面，但这个库需要早于任何游戏逻辑代码运行，如何做到？）
这个不是很清楚，没有相关的处理经验，我们公共库的做法是放在大厅里面，bundle里面放一份.d.ts
替代了cc的方法是什么？ 我没看懂 现在就是Sprite Label 直接写是需要引入命名空间吧 但是没找到要引用哪个 你用cc.Sprite 会提示已经弃用
只能用import * as cc from ‘cc’; cc.Sprite才算正常
所以cc被弃用后 新的UI命名空间到底是什么？？现在拖一个UI组件 上面也是Label 也是cc.Label
同感，不带cc有时还有歧义。比如用creator3.3新建一个脚本，写个Animation类型变量，没有从cc导入，也不会飘红，点进去发现类型提示跳转的似乎是编辑器api的Animation，不是cc的动画组件，进而在creator中也没办法绑定变量。
说句真心话，看到这个就不想迁移到3.0了。tree shaking这种级别的优化真的没那么重要，相反coding层面的便利性可能更重要。
1赞
一年了，tree shaking 功能上了吗
负向优化,以前写起来很方便cc.就出来了,现在写起来超麻烦,熟悉api还好,不熟悉就得一边翻文档一边写
确实，现在写Node老是不小心指到NodeJS的Node
3赞
可能是为了对标unity吧
可能大佬不是同一个人吧，大佬不一样，代码风格就得作妖一下。
1赞