之前想的等正式版出来就处理这个事情。居然忘记了。。。
构建工具升级，让框架中的所有库已经同时支持commonjs和esm规范的库了。
模板中使用了模块管理库，编码、使用和运行都如2.x一样，不需做何改变。
理论上其他库也一样（基本不会打脸，如果有问题，轻点。。。）
欢迎大家体验和拍砖。
项目模板传送门:github
其他项目模板可见:模块管理-文档
框架传送门:EasyGameFramework-github
最近github很难打开，大家有没有感觉。。。
放个gitee地址:EasyGameFramework-gitee
打嗝 你这个模块都放到 npm仓库上， 以后更新合维护都比较困难； 调试起来也不方便
以后线上问题怎么排查？
另外支持 Native吗？
项目模板就不放npm了
调试怎么不方便呢？有sourcemap，有声明
线上问题怎么排查？你指的是什么问题呢？
native为啥不支持呢？如果cocos脚本支持，那这也应该支持
以后会通过脚手架创建项目模板
大哥哥， 你的这个设计思路挺好的； 但是我不想用npm； 看看你的设计思路， 我们有什么可以借鉴的。
说设计思路的话。
不想用npm？不太明白
我猜你可能不想将东西发布到公共的npm库，甚至不想发布。
另外一方面，可能为了方便调试。
而且框架相关的一般相对稳定而且有对应的单元测试和例子测试。不会频繁改动
所以呢，我用monorepo的项目结构开发
开发的库不用发布也可以给项目使用。
如果不想发布公共仓库，可以搭建一个本地仓库，或者局域网内仓库，搭建也非常简单：使用Verdaccio
关于monorepo具体可见仓库readme
:EasyGameFramework-github
最近github不太好使啊
贴一个coding的仓库
https://e.coding.net/AILHC/easy-game-framework/EasyGameFrameworkOpen.git
支持。
代码维护是git干的活，npm只是管发布更新。。。。
git打好release tag然后推送npm就完事了，非常合理方便的维护方式额。
我们也是准备用npm进行模块化管理，
但搭私有包管理服务，使用gitlab，接入自动发布。
这样更省事了
使用的人直接npm install/update完事
github最近经常抽风
gitlab只是用来替代github的额，
加上ci脚本做npm发布。。。。。
不是package的公私包，是指我们在自己服务器上搭建npm包管理。。
nexus或verdaccio
对，有点烦。
还好我还有备用仓库 coding
我用verdaccio
是不是又一次将CREATOR变得复杂了！
怎么变复杂呢？我又没动Creator
将通用的模块抽离，并且使用成熟的npm来进行模块管理和版本管理。方便多个项目之间进行模块复用，将项目开发变简单。
如果按照简单的方式，我将框架的所有东西都写到一个项目里，大家都克隆，复制粘贴，有需要的模块留下，不需要的删除，需要处理被删之后模块间耦合的错误。如果有bug修复，升级迭代，都一行一行比对，或者找提交记录，然后再复制粘贴到自己项目，或者（因为自己改过）参照框架作者的逻辑修改，还得测试看有没有问题。
这样框架作者不知道会不会影响你的项目，他得顾及自己项目。这是简单开启，复杂的维护。
我的框架，是复杂和丰富我的框架维护体系，建立这个框架体系的开头是困难的，但后期的维护和迭代是简单的，让每个模块尽量职责单一，可以单独单元测试，规范的提交日志，自动生成的更改日志（看一眼就知道要不要升级）。
使用者可以轻松按需取用
支持广泛，支持2.x和3.0
我说的是开发模型变复杂了。如果说游戏的设计就是复制代码。那数据驱动就没有意义了。
游戏引擎大多是站在 ：游戏业务层（偏向策划） 向前发展
游戏框架大多是站在：游戏代码开发层（偏向程序）向前发展
最后就会走出两条不交叉的曲线，让刚入行的新手一看就跑了。学习成本被拉升了。
现在有了CREATOR是不是可以不要如此分裂了呢！（数据驱动的本意不应该是尽量简化代码吗）
这个得看新手的选择了。
如果懒，那么用老实用编辑器。
如果是想让项目更健壮或者想通过框架提高开发效率，那就用框架，或者开发框架。
框架不是银弹，引擎和编辑器也不是银弹
当项目复杂到一定程度，框架的开发效率和迭代效率可能会更高
不过框架也并非完全和引擎不相交，也可以和编辑器深度结合。
你觉得在一个10万行代码以上的项目里
让新人看整个项目的代码容易，还是说告诉他有哪些模块，然后去看模块文档容易？
没有框架，没有模块化的项目，只会一开始容易，然后越开发就越进入不可维护状态。
除非这个项目本来就没多少代码。
