search

imperodesign / generator-impero

Impero's website skeleton generator, courtesy of Yeoman
Other
1 stars 1 forks source link

Remove support for transpiling experimental features #35

Closed MrSlide closed 7 years ago

MrSlide commented 8 years ago

Supporting ES2017 will promote the use of experimental features, which later on can be problematic as those feature specs change and they become supported by the browsers. I suggest that instead those features become supported by the use of libraries instead of polyfills or transpiling the code to ES5. By only supporting stable features, we can guarantee that the code will still be valid in the future.

pvalentim commented 8 years ago

Agreed, I still think we can use ES2017 in special cases but as a default I would remove it.

samhh commented 8 years ago

I'm okay with this, but I'm not sure how strong the stable features argument is. I find it inconceivable that at any point in the future we won't be using some form of transpilation for bleeding edge features/ideas.

MrSlide commented 8 years ago

I would avoid transpilation of experimental features, instead I would opt for a library that does the same, but which wouldn't be changing the API later on as the specs change or as the browsers start supporting it. Also, using a library instead for experimental features, means that once the specs for the feature become final and start being supported, those libraries can just become an abstraction layer, without having to refactor your own code.

samhh commented 8 years ago

Presumably if the API or specs (breaking) change within the presets then they'll bump the version per semantic versioning, so I can't see how it would cause an issue. Your dependency would still be the one that works as you're expecting, and after that this generator can be updated.

Where would you draw the line? ES2015? ES2016? ES2017?

Are there any libraries that allow you to add an exponentiation operator like in ES2016, for example?

samhh commented 7 years ago

Having mulled it over I'm now content to at least remove stage-1 preset and just manually add support for class public fields to my projects individually (also, this has since been promoted to stage 2 - yay!). Whilst I don't think keeping it would often incur technical issues, it could do if you became reliant upon some to-be-unstandardised code in a big project. Nobody wants that.

Is the reasoning for removing es2017 preset that unlike es2015 & es2016 it is still in draft and not finalised?

@MrSlide @pvalentim

MrSlide commented 7 years ago

I would draw the line wherever is the current standard. If it's not a standard, don't support it by default. When I said that the API or specs would change I didn't mean it in the Babel presets or plugins, I meant the actual W3C specs. If you have the specs changing and the function names remain the same but the accepted arguments change (as happened before) then you're left in a situation where the transpiler might have no idea what to do, or you have to do feature support checks and include both syntaxes in your code. Either way, it's a situation that is best to avoid.

samhh commented 7 years ago

Okay, that makes sense. I think we'll cap it at ES2016 until ES2017 is finalised and then add that one back in. Approved 👍

samhh commented 7 years ago

https://github.com/imperodesign/generator-impero/commit/2842dd46ef6cb7acd0f1d5aec68d0531de11ae95

samhh commented 7 years ago

@MrSlide @pvalentim Does this signify that ES2017 is finalised? https://tc39.github.io/ecma262/

I've noticed also that Babel's preset page does not list it as experimental (I'm not sure if it ever did) here: http://babeljs.io/docs/plugins/

samhh commented 7 years ago

Even if it isn't finalised, it appears that the two plugins included in the ES2017 presets are (async functions and trailing commas):

https://github.com/tc39/proposals/blob/master/finished-proposals.md

samhh commented 7 years ago

All of es2017 is now at least stage 4, meaning that the specs are finalised and it should be safe to include.