Restrict code to ES5

[saghul]

Great progress Fedor!

If this tool is to be used for compiling Node, I'd say it should be written without any ES6 features, so Node 0.10 can be used to build the latest Node.

Ideally with no dependencies. If someone is starting from zero, something like a small bootstrap VM built using Duktape could be used.

[indutny]

Thank you, Saul!

I was going to use Babel for this purpose, and duktape is in my plans
indeed! 😉

On Sunday, June 12, 2016, Saúl Ibarra Corretgé notifications@github.com
wrote:

Great progress Fedor!

If this tool is to be used for compiling Node, I'd say it should be
written without any ES6 features, so Node 0.10 can be used to build the
latest Node.

Ideally with no dependencies. If someone is starting from zero, something
like a small bootstrap VM built using Duktape could be used.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#9, or mute the thread
https://github.com/notifications/unsubscribe/AAOjw7TJqCIAaSyyXYvoHtlT04AqMC4Oks5qLIO2gaJpZM4Iz5gW
.

[tejasmanohar]

@saghul I'm not @indutny, but personally, I don't think that's necessary. If someone is starting from point zero today, they should be using a later version of Node.js. I suggest we keep things moving forward so long as it works without flags on LTS.

[tejasmanohar]

@indutny Interesting. Babel works, too.

[kzc]

Perhaps a minimal subset of fs, util, process, path and child_process can be made for duktape.

@indutny Is all this code all synchronous or are there any async parts relying on an event loop?

[indutny]

@kzc no async parts. I'm going to isolate all node.js bindings into a separate JS file, so it would be easier to shim them.

[indutny]

Some of them could be take from browserify, obviously. Like util.

[kzc]

For ES6 to ES5 conversion buble has fewer dependencies and is much faster than babel. Mind you, it supports just a subset of ES6.

https://gitlab.com/Rich-Harris/buble

[indutny]

@kzc I'm not sure if dependency count matters that much, considering that this step will happen only on duktape builds.

[kzc]

I guess if gyp.js is translated to ES5 and browserify'd for duktape and distributed with node in that form then it doesn't matter whether babel or buble is used to make it.

[indutny]

There is no point in distributing it in ES5, ES6 is just fine for the latest node.

[kzc]

ES5 gyp.js could be used for backports to bootstrap node itself.

[indutny]

@kzc true, though not too much reason to do it with older versions of node.js . So ES5 IMO should be used only to provide a binary with duktape.

[kzc]

ES5 gyp.js with duktape + bindings shim could bootstrap node itself with only a C++ compiler.

[indutny]

Yeah, I agree. This is reflected here: #4

[saghul]

My point here was twofold: a) same as @kzc, but b) it should probably be possible to build Node with whatever (reasonable) Node in the PATH already. For b) that's 0.10 on Debian stable.

What are the ES6 features a (relatively) small library like this can't live without? IMHO it's simpler to not have to even transpile the code.

@tejasmanohar It's not reasonable to tell someone: "hey, download Node 4 in binary form in order to be able to compile Node 6". Node should be able to self-bootstrap.

[tejasmanohar]

@saghul Ah, I missed the original concern- self-bootstrapping. If that's the case, I'd also suggest avoiding transpilation just because I don't think it offers major benefits.

[indutny]

I'm inclined to close this issue as a won't fix. Any objections?

[indutny]

My arguments are the same just in case, transpiling should help us move forward for now, and we are not even sure if this tool will be distributed standalone at this point.

[RangerMauve]

I'm thinking that if anything, transpiling could be added once people actually start using this in the wild with older node versions or whatever else. I doubt it'd be hard to add in, and I also doubt that switching back to ES5 would be too difficult if it was really necessary.

[indutny]

Ok, let's keep this issue open then. Valid argument.

[RangerMauve]

Well, I was actually thinking that it'd be OK to close it for now and then re-open once somebody really needs it. But that works too. 👍

[saghul]

✋ I object :-) That means we'd have to bundle the transpiler, plus the dependencies this thing already has 😭 making this whole thing a lot bigger than it really needs to be IMHO.

Also, I'm not sure if you considered it (or if it ever was one of your goals), but this tool could be used by others also wanting to dump the Python dependency GYP currently has implies.

[pmed]

Sticking to ES5 would allow to use gyp.js in node-gyp. Actually, I only see few ES6 features (function default parameters and destructuring assignment) in the gyp.js code that do not work in older stable Node.js versions.

I tried gyp.js with Node.js 4.4.5 in a branch es5, and it worked well.

[saghul]

@pmed 4.4 might still be too recent. 0.10 will be EOL in october and it's packaged in Debian Jessie (stable) so I'd hope it works there.

[kzc]

If an ES6 gyp.js is transpiled to ES5 and browserify'd and bundled with node releases in that form it could be workable with duktape - but it's not ideal.

[indutny]

@saghul sticking to v0.10 means:

• no arrow functions
• no const/let
• no default argument values (I guess we can live without it)

[ibc]

Please, just use ES6 and avoid Babel.

@saghul please, forget node 0.10 and let's move forward.

[kzc]

@ibc Duktape only supports ES5. This can remove the python dependency on bootstrapping node.

[ibc]

@kzc Duktape should update. ES6 is one year old.

[kzc]

Duktape should update. ES6 is one year old.

That's not practical.

[indutny]

@ibc pointless, though? Why should they emulate stuff that can be shimmed/transpiled?

[saghul]

@indutny all of the things you mentioned sound like minor inconveniences here, AFAIS.

@ibc I like ES6 as the first guy, but I'm trying to suggest a pragmatic approach here. If I want to deploy Node vX to production which uses this new gyp.js I should be able to bootstrap it without third-party binaries. If my distribution ships Node 0.10 it would be ideal if we can use that, falling back to a Duktape based tiny bootstrap interpreter. What you suggest is not reasonable, Duktape is not going to get full ES6 support overnight.

[kzc]

If ES6 speed relative to ES5 is a concern:

https://kpdecker.github.io/six-speed/

[indutny]

I have restricted the code to the limited ES6 subset: only const and let. It appears to be working on v4, v5, v6 node.js at the time.

Still, I kind of like the fact that it could be checked for const-ness with the help of eslint. Should we leave it this way and just use Babel for duktape?

[ibc]

Node 0.12 does not support let. So there are 3 choices IMHO:

1. Drop ES5 support (bye ES5 and Duktape).
2. Use Babel so npm i gyp.js installs a just ES5 library.
3. Publish a separate gyp.js-es5 NPM package.

[saghul]

@ibc How do you plan on running npm if you don't have Node built yet? It's a chicken-and-egg problem, we're talking bootstrapping here.

[saghul]

@indutny If you decide to go the Babel route it doesn't really matter how much ES6 you use anyway, does it? :-)

[indutny]

@saghul well, at least this code will work without transpiler on v4 node.js

[ibc]

we're talking bootstrapping here.

I thought the main purpose of gyp.js was to remove the Python dependency for building Node native modules (rather than building Node itself).

[indutny]

@ibc we haven't decided yet 😢

[ibc]

we haven't decided yet

Then I suggest deciding "what" prior to "how" :)

[indutny]

Good idea!

[ibc]

@indutny I have taken the liberty of suggesting the list of use-cases in #19, so this issue can focus on the original subject ("restrict code to ES5").

[indutny]

@ibc thank you!

[indutny]

Closed by: https://github.com/indutny/dukgyp