nodejs
iojs -t
Transpilation is here to stay. Even though IOJS ships with some ES6 features, I find myself using babel-node all the time because I want other features that are not presently supported.
It's not only about ES6 compatibility, though. Transpilation can enable the usage of hygienic macros, add better instrumentation and enhance debugging, introduce proprietary features (JSX), among other things.
I propose the support of first-class source transformations in two ways:
Declarative (CLI)
This is essentially the same as browserify -t. It's possible that due to the usage of streams (yay for great abstractions), we can even reuse some of the same transforms.
$ iojs -t babelify woot.js
should make ES6 code work.
Programmatic
This is a substitute to what I consider a weird API / implementation detail: custom extension handlers.
require.transform(require('babelify'));
it's possible that this API could be polyfilled to use extension handlers for BC or compatibility with Node.
note this may be at least partially solved by https://github.com/iojs/io.js/pull/881 if it ever lands
@chrisdickinson #2 is very valid. I still advocate for always transpiling prior to publish to remove the runtime performance penalties.
However, for things like instrumentation, you still want to quickly toggle between transpilation and no transpilation.
What does this have to do with weakening our stance that all npm modules should publish as vanilla js? npm published modules can't change the command line arguments of node, publish modules relying on node's arguments doesn't work well (koa withstanding).
Any use of this for transpilation would be occurring pre-publish during development, for example:
/bin/ls | entr -cr node -r 6to5 test/fu.js
I really like how browserify does this by adding a browserify.transform field to package.json. If that is implemented, then the modules can use transforms without needing to do the transformation pre-running. That is really useful when you are writing substack-style and are working on multiple modules at once.
I've spent a fair amount of time screaming at browserify transform and overlay declarations in package.json. In general I think it's better to enable a single endpoint (like, "install" or "build") that calls some code and allow people to write things in code rather than through configurations.
@rauchg Do you think the (newly-added) -r feature addresses this concern, or would you like to have something more full-fledged on top of that (some sort of way for require.extensions to cooperate, for example?)
I was thinking about something like a shebang for node.js modules to make require.extensions cooperate with each other. So you would specify package@version in such a file, and node.js will load it with an appropriate module. Not sure now useful it is.
