new Class() replace to esm class syntax

[LjjGit]

我用 PHP 脚本和正则表达式对源代码的 new Class() 结构进行了替换。
这样做的好处有：

1. 静态语法
2. 标准语法
3. 可以静态分析，对编辑器更友好
4. 可以渐进式拥抱新语法
5. 逻辑更清晰
6. 支持语言层面的约束

还有很多。

这种批量替换源代码的做法，我是有经验的，我自己有实际使用，就是用本项目的源代码实践的，可以成功运行，且有实际生产环境的游戏。并且我的做法更彻底更激进，require()这些都替换成了 import from，var 替换成 const 或者 let 等等。

现在有个遗留问题，esm的语法要求调用super()之前不能访问this。这个可能需要主力开发者手动修复一下。

在src/a.php里有替换逻辑，可以checkout出来查看。只有一个commit是用了这脚本替换的，其他commit是手动修改的。

由于我的英文表达很差，这里就用中文代替了。
附上谷歌翻译

I used PHP scripts and regular expressions to replace the new Class() structure in the source code.
The benefits of doing this are:

1. Static syntax
2. Standard syntax
3. Can be statically analyzed, more friendly to the editor
4. Can gradually embrace new syntax
5. Clearer logic
6. Support language-level constraints

There are many more.

I have experience with this practice of batch replacing source code. I have actually used it myself, that is, I practiced it with the source code of this project, which can be successfully run and has a game in the actual production environment. And my approach is more thorough and radical. require() is replaced with import from, var is replaced with const or let, etc.

Now there is a legacy issue. The esm syntax requires that this cannot be accessed before calling super(). This may require the main developer to manually fix it.

There is a replacement logic in src/a.php, which can be checked out. Only one commit is replaced by this script, and the other commit are manually modified.

Since my English is poor, I will use Chinese instead.
Attached is Google Translate

[LjjGit]

但没有单元测试，合并起来可能会很困难。贴出来给大家参考一下也有意义。

But without unit tests, merging may be difficult. It makes sense to post it here for your reference.

[ospira]

interesting attempt at this... as long as you are doing this, can you try an ECS rewrite next? 😅

speaking of the components/mixins... i think this looks wrong: https://github.com/phaserjs/phaser/pull/7113/files#diff-b6ae4879280c321a1d19939b0b106161414a844463b703c4872bb16daf104cdbL61-R79

...but then again you might be correct. personally, if this is going to be rewritten i would prefer a more functional style. i doubt this is going to get merged but as someone with no influence over this i still appreciate you taking a random whack at it 😄