ES6 class definition & module support #915
Comments
and keep removing polyfill not required since the mimimum browswer requirement as listed on the website.
|
Oh I am really looking forward for v6 Thank you for taking care of this! |
75% of classes done, but the whole build process is broken :)
|
@obiot How can I help move this along? I would really like to use your game engine over Phaser due to the simplicity this provides, but non es6 and non npm available makes it extremely difficult to use with typescript. I have a large amount of time I could commit to moving this project along, and only need a quick pointer to get started (ie. "Can you start converting these files" / "This is the next goal ____ start here") |
|
@SnareChops Well I would looooove some help on this to be honest, I've been side tracked recently, and this is taking much longer than I initially expected... In terms of progress though I almost converted all the classes to the ES6 syntax, what is missing is a few of them, and the whole build process that also need to be updated. So if you really have a lots of free time and want to help you can start by looking at the below branch and either finish converting the classes definition and/or update the build process (for the converted classes) + run one of the example against it : Can't thank you enough in advance for any help you can provide on this one :) As for the master branch, I was planning (will do so shortly) to release an intermediate release with the current changes that includes cleaning of the API (to ensure melonJS is properly isolated within its own namesake) and all the bug fixes from the 5.x branch. |
|
@obiot So what's the plan for the ES6 branch for now? Is it going to be synced with master at some point? Also I can't say that I have lots of free time, but I have some - what would be the top priority tasks at this point to push it all forward? |
|
@obiot So I think I'm going to need to bow out from this one. Some of the files are very easily converted, but others where the rule of single responsibility is broken is very difficult due to the design architecture of the application. To properly convert will be a much larger undertaking than you may have initially expected due to the organizational structure that the library was written in. At this point I don't actually recommend converting the library to ES6, but instead create an ES6 wrapping layer over top of the ES5, then slowly convert file by file to ES6 as time goes on. Proper organization is critical for ES6 and following a strict rule of "Single Discreet Responsibility" within your files will make the transition much simpler. I attempted to convert as much as I could and did convert every file in the project to ES6, but when trying to tie all of the imports together the problems really started to reveal themselves, and out of respect for you and your other contributors I decided not to start taking extreme measures completely reorganizing your project, though I feel thats what it really needs to make the transition properly. By placing an ES6 wrapper over the ES5 code and reorganizing piece by piece, compiling with a babl / webpack pipeline should allow you to continue with releases while this process is going on, rather than having a branch getting stale during the conversion and then dealing with the metric ton of merge conflicts at the end attempting to pull in all of the updates from master. If you should want or need it my fork has my completed work, but would advise against trying to use it due to the reasons that I stated above. Best of luck with the project and I'm sorry that I wasn't able to achieve the goal, I just didn't want to cross any boundaries and disrespect you or your other contributors by reorganizing everything and making major changes to the entire project. |
|
I'm for typescript also. It catches a lot of errors, is very non-intrusive to writing javascript, and it's self documenting as you write, along with auto-complete parameters and methods. I can't convey how much typescript makes javascript so much easier to work with into words but if the melonjs team still doesn't like typescript after testing it out, I stand behind the decision! tl;dr just make a fully informed decision |
|
@SnareChops sorry for the late reply. Yes indeed the library conversion is a long task and imply rewriting/refactoring several major part of melonJS.... don't worry, I totally understand your point and definitely thank you for what you did try. I'm interested though in your current work/progress, even though incomplete, It can help me progress by filling the gap with what I did so far (you can send a PR on the ES6-update branch, or send it by email to me at olivier.biot@me.com). As for the ES6 Wrapper, it would definitely be nice to have, although I'm really wondering what is the added value at this stage, considering the current "Jay" inheritance model. And looking at my recent adventure with WeChat mini-program that requires ES6 (see here), it kind of gave me a feeling of the limit of such a wrapper (but maybe I'm wrong). |
|
@scarejar I don't have anything against Typescript actually, just I never really used it (nor needed it), and to be honest everytime someone came up with the request and a proposal for a PR it never went through. I agree though that TS allows to better highlight API discrepancies, and last time the topic came up, we modified/improved a few things (maybe it was with you, I do not remember). Now if you are willing to help on this and up to task ...:P I'll be happy to start over, implement further changes in the current API, and probably try to use something like |
|
@obiot If you want to get started into typescript you don't need to convert anything. Just rename the files from Though if this is your first time I do recommend trying it out with a very small 2-3 file test project so that you can get your As for my work you should be able to pull it in yourself if you really want (https://github.com/SnareChops/melonJS/tree/ES6-update) |
|
@obiot Please let me know if I could contribute to the merge somehow. |
also fix a circular dependency between rendererable and container
|
now that basically only remains to finalise the migration to es6 inheritance for the remaining classes, closing this one and opening a new ticket : #1021 |
This ticket list all the related tasks required to migrate to es6 and using a module approach. Until fully stable, the current build process will however keep transpiling everything to es5 and generate a es5 umd module. Ultimately the goal is to generate two different build :
melonjs.jslegacy es5 build for legacy browsers/devices (to be decided yet at which level we keep some backward compatibility with regard to the current Jay inheritance mechanism vs a standard es5 here)melons-module.jsa es6 module based version for modern browser/devices (use es6 inheritance mechanism)Migration phases :
ES6 class semantic : to replace the current Jay inheritance mechanism (see also Critical: MelonJS 2.1 doesn't work on Chrome v43.x (maxTouchPoints issue) #685) :
~~ES6 module export : to allow generating a es6 bundle:
me.sys(remove/deprecated)ES6 module support : with potential option to build tailored version of melonJS with only selected modules-> structure and build process in place, rest will be done gradually while converting the above class definition to es6deprecated API : include this automatically in the build process only once (after) the transpiling to es5
[Replace XHR with window.fetch (polyfill) #678] window.fetch : might not be that widely supported, but a polyfill can easily be added, see https://github.com/github/fetch
BabylonRollup Bubble : to automatically transpile and generate an ES5 build.I will close all the ticket referenced in this one, just to avoid having the same topic covered in different places.
Feel free to comments here under !
The text was updated successfully, but these errors were encountered: