New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ES6 & others #915

Open
obiot opened this Issue Jan 11, 2018 · 11 comments

Comments

Projects
None yet
5 participants
@obiot
Member

obiot commented Jan 11, 2018

With the 5.x branch of melonJS where support for legacy browsers was dropped, and most moderns browsers (not to say all) now supporting ES6, there is no reason anymore to postpone this (Cocoon.io also announced support of ES6 in their latest 2.2.0 version).

This ticket therefore list all the related task related for the next 7.0.0 milestone (see the related blog entry as well here) :

  • [#703] non-intrusive language extensions : to make sure melonJS is fully isolated within the me namespace. > This will be part of an intermediate release (6.0.0), as the full es6 lib is having some delay
  • ES6 class semantic : to replace the current Jay inheritance mechanism (see also #821)
  • ES6 module support : with potential option to build tailored version of melonJS with only selected modules
  • [#678] window.fetch : might not be that widely supported, but the polyfill can easily be added through Babylon (see below) by using import 'whatwg-fetch'
  • Babylon (Polyfill, transpiling) : to automatically includes required polyfill, and/or generate a amd + es5 build if required.

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 !

@obiot obiot added this to the 6.0.0 milestone Jan 11, 2018

obiot added a commit that referenced this issue Jan 21, 2018

[#915,#703] Non-intrusive language extensions (1st round of changes)
new me.Math api that will grow along with other items removed from native objects.

obiot added a commit that referenced this issue Jan 23, 2018

[#915][703] keep moving things around
and keep removing polyfill not required since the mimimum browswer requirement as listed on the website.

obiot added a commit that referenced this issue Jan 27, 2018

obiot added a commit that referenced this issue Jan 27, 2018

@itsjavi

This comment has been minimized.

Contributor

itsjavi commented Feb 23, 2018

Oh I am really looking forward for v6
I am currently doing nasty things in order to use Melon with Webpack and Babel as you can see: https://github.com/pokettomonstaa/NewBark

Thank you for taking care of this!

obiot referenced this issue Mar 15, 2018

first commit with converted es6 syntax and module definition
75% of classes done, but the whole build process is broken :)
@SnareChops

This comment has been minimized.

SnareChops commented May 26, 2018

@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")

@obiot

This comment has been minimized.

Member

obiot commented May 28, 2018

@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 :
https://github.com/melonjs/melonJS/tree/ES6-update

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 obiot modified the milestones: 6.0.0, 7.0.0 Jun 1, 2018

@obiot obiot changed the title from melonJS 6.0.0 : ES6 & others to melonJS 7.0.0 : ES6 & others Jun 1, 2018

@kibertoad

This comment has been minimized.

Contributor

kibertoad commented Jul 4, 2018

@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?

@SnareChops

This comment has been minimized.

SnareChops commented Jul 8, 2018

@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.

@scarejar

This comment has been minimized.

scarejar commented Jul 10, 2018

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

@obiot

This comment has been minimized.

Member

obiot commented Jul 11, 2018

@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).

@obiot

This comment has been minimized.

Member

obiot commented Jul 11, 2018

@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 grunt-ts to automatically generate the TS files ?

@obiot obiot changed the title from melonJS 7.0.0 : ES6 & others to ES6 & others Jul 17, 2018

@SnareChops

This comment has been minimized.

SnareChops commented Aug 23, 2018

@obiot If you want to get started into typescript you don't need to convert anything. Just rename the files from .js to .ts and run through the typescript compiler, that's all that is needed since any valid javascript is valid typescript. (Typescript is an extension of the base javascript language, not a different syntax like coffee script or anything like that)

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 tsconfig.json file set the way you want and get that initial understanding of how the compiler works / exports files.

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)

@kibertoad

This comment has been minimized.

Contributor

kibertoad commented Aug 23, 2018

@obiot Please let me know if I could contribute to the merge somehow.

obiot added a commit that referenced this issue Sep 4, 2018

[#915] added a es2015 babel task
does not do much for now, and not automatically called during the build process
@obiot

This comment has been minimized.

Member

obiot commented Sep 4, 2018

Thanks guys ! I just added a babel task. It's not yet automatically called during the build process, but we can enable this as soon as we start adding es6 elements.

As I was saying earlier I think that a good idea would be to progressively introduce the new syntax, maybe in the following order :

  • fetch API (as listed above, and use babel to include the required polypill to XMLHttpRequest)
  • ES6 New Constructor at least first to user non instantiable class (e.g. renderer, utils, etc...)
  • Modules
    with Babel allowing to then transpile to es5 until it's fully es6 compliant :P
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment