code option when bundling

[Rich-Harris]

esperanto.bundle() has a skip option, which allows certain modules to be skipped - useful if you want to (e.g.) omit the IE8 polyfills, or whatever - but it would be more flexible to do this instead:

src/main.js

import foo from './foo';
import './polyfills';

foo();
// ...

build step

esperanto.bundle({
  base: 'src',
  entry: 'main',
  code: {
    polyfills: '{}' // overrides contents of polyfills.js
  }
}).then(...);

This would be a step towards allowing the bundler to work in environments that don't have fs (i.e. browsers).

It would probably make sense to deprecate skip, by converting skip: ['polyfills'] to the above, and printing a console warning.

[scottgonzalez]

While the code option is a more straight-forward approach, it seems like this can be accomplished today with the transform option.

I actually want to do the opposite of the example, having modules that use newer functionality, then creating a separate build that injects polyfills or equivalent APIs for older environments. Let's use an example of building forEach without modifying native prototype. You could have a forEach module that just exports Array.prototype.forEach, and a compat/forEach module which implements the same API in ES3. Then a custom build can replace the forEach module with the compat/forEach module. The code option would make this easy, but can you think of any drawback to just doing this with a similar mapping of modules to replacement code using the transform option for now? This is kind of like using require.js' path option to swap out an equivalent module dependency.