Add importHelpers option

[lukescott]

Adds importHelpers option that causes used helpers to be imported as an external file. Works well with gobble-esperanto-bundle.

Example:

var gobble = require("gobble");

module.exports = gobble("app")
.transform("babel", {
    blacklist: ["strict", "es6.modules"],
    importHelpers: true
})
.transform("esperanto-bundle", {
    entry: "index.js",
    type: "umd",
    name: "myapp",
    dest: "myapp"
});

The .babelrc file is also respected (wasn't before).

The only thing I haven't figured out is the map file generated by esperanto-bundle is referring to the .gobble-build directory.

[Rich-Harris]

Thanks for the PR, I love this idea! More than a couple of times I've grumbled to myself about having classCallCheck and stuff like that repeated inside bundles (though I never got round to actually fixing it.)

I'm ambivalent about merging this PR though, because it will defeat one of gobble's most important optimisations - only re-transpiling when an input file has changed. File transformers get this for free, but that's not possible with directory transformers (currently working on a good, robust API for letting directory transformers know which changes have happened since the last successful run).

Definitely worth stewing on for a while though, it'd be great to have this feature, and it might well be possible to do while keeping it as a file transformer. I've raised #6 separately for the .babelrc thing (another good call, thanks)

[lukescott]

Yeah, I know what you mean. The current issues with the single file transformer is:

• There doesn't seem to be a way to pass state of the file transformer. This is important in order to keep track of which helpers were used. Perhaps something on this (bound to the function)?
• There doesn't seem to be a way to tack on a "finisher" after all the files have been processed that can add another file.

I think that as long as a single file transformer can return undefined (no file) and the above are addressed you won't need a inputdir/outputdir transformer... [edit:] although scratch that gobble-esperanto-bundle needs to look at every file. But if we could get there you could even make the files memory bound, which would be exciting.

I also wish that babel had an option to inject a babelHelpers import on files that need it.

[Rich-Harris]

@lukescott FYI I've just released 5.1.0, which at least adds .babelrc support.

There doesn't seem to be a way to pass state of the file transformer

Yeah, it's a classic simplicity versus performance trade-off. I really like having 'pure' transformations - adding state into the mix feels like a quick way to guarantee bugs - but it does mean that certain things are impossible. Haven't had much of a chance to mull over this issue but I'm still keen to figure out a decent approach.

But if we could get there you could even make the files memory bound

I've occasionally wondered about that. At the moment, sourcemaps are stored in memory (rather than e.g. being added as //# sourceMappingURL=... comments and .map files), because transformers don't need to know about sourcemaps from previous transformations, only the code itself. For some cases (sequential file transformers), storing files in memory as well could provide a boost. So far we haven't done that because a) it's way easier to debug a tricky build definition when you can view the results of all the intermediate transformations in a text editor, and b) I was strongly influenced by this blog post, which argues (among other things) that directories rather than files are the right level at which to think about these things, and that the overhead of using the filesystem directly is generally overstated (most operations are CPU-bound, and also because swapfiles). I definitely wouldn't rule it out though.

I also wish that babel had an option to inject a babelHelpers import on files that need it.

That'd be neat. It would mean that babel would have to be aware of the source module type (couldn't necessarily assume ES6 modules), which might make things slightly more awkward.

Is the runtime transformer something that could help here? I haven't really looked into it yet, but it might at least point us towards a solution.

[lukescott]

@Rich-Harris:

Re: Passing state - It would be useful within the same transformer, not necessarily between different transformers. That is if you have some sort of "final" transformer that can do something with it. It's more for adding a new file(s) at the end, whether that be concating all the files, adding helpers, or adding a source map file.

Re: memory vs files - It really depends on the system. Memory will always be faster as long as you have enough of it. SSD disks can be very comparable. If the transformer only dealt with one file at a time, it doesn't have to worry about the file system. At that point you can make memory vs files configurable.

Re: runtime transformer - I didn't know about that! I just tried it and it got me almost there. Unfortunately I have the following issues:

• It's replacing stuff like Object.keys with _Object$keys. I currently would need to turn that off.
• I'm using the Esperanto bundler w/ es6.modules blacklisted, so it tries to include, for example, babel-runtime/helpers/inherits externally. Need that to be included as if it was local.
• The inherits helper uses __proto__, which isn't compatible with IE 10 and below. This helper, when inline, gets transformed when using the spec.protoToAssign option. With this branch I had to transform the helpers.