[feature request] inline all imports into a single file

[samccone]

Use case:

You create a library/tool that has dependencies.
You want to distribute your library in a UMD format (and have it work in the browser without a user having to use something like system.js to polyfill "require")

Current solution:

Using browserify to do the inlining work or create a custom build system to support this.

Ideal solution:

A flag to enable this joining inside of babel.

Why does this belong in core?

If you support exporting to UMD, then for it to be truly universal inlining the dependencies is essential.

Thanks 👾

[sebmck]

This was discussed in #495 but closed since there were bigger things to worry about then. Now seems like a good time to resurrect it. cc @zertosh who I know is interested in integrating Babel more tightly into module bundling 😄

[gaearon]

Why should Babel support this? Don't Browserify and Webpack solve this problem well with an ecosystem of plugins, servers, watchers and other dev tools?

(Not being snarky. Genuinely wondering.)

[zertosh]

@gaearon browserify and webpack kinda solved it, but having multiple source->ast->source steps really limits what you can do. Erasing the division between packaging and transformation makes sense. Think about it, packaging is just another transformation that just so happens to span multiple files.

[samccone]

@gaearon I agree 100%

Why should Babel support this? Don't Browserify and Webpack solve this problem well with an ecosystem of plugins, servers, watchers and other dev tools?

If we wanted to take this further as @sebmck and I talked about in meatspace:

I think module formatters and the watcher should be dropped from babel... but until we do the great strip down of the library into a just a code "transformer", this enhancement does have a place.

🐳 💿 🌾

[calidion]

+1
browserify or webpack are a seemingly poor tools for packing.
like java's obfuscation, packing and uglifying into a file is very important for both front end and server back.

[cesarandreu]

I'm not sure of the benefits of having babel generated bundles. I let Webpack handle all of this functionality, and babel is just another transformer in the pipeline.

Why are browserify or webpack bad tools for packing?

[engma]

+1 it would be really awesome to just use this in babelJS, since it would be a one step conversion

[zbraniecki]

I wrote a very minimalistic es6 bundler as a plugin for babel.

You can find the source code here: https://gist.github.com/zbraniecki/649e0390d57ac353494d
(it requires a small patch to babel that landed here: #1951 and should be in the next release)

It looks like this:

It turns sth like this:
./src/lib/core.js:

export function foo() {
}

./src/runtime/web/index.js

import { foo } from '../../lib/core';

into:

'use strict';

(function (global) {
  const modules = new Map();
  const moduleCache = new Map();

  function getModule(id) {
    if (!moduleCache.has(id)) {
      moduleCache.set(id, modules.get(id).call(global))
    }
    return moduleCache.get(id);
  }

  modules.set('lib/core', function () {
    function foo() {
    }
    return { foo };
  });

  modules.set('runtime/web/index', function () {
    const { foo } = getModule('lib/core');
  });
})(this);

It allows us to remove webpack from the toolchain (which is important because webpack cannot work on not-transpiled es6 code) and gives us a very readable output because the modules look as close to the original files as possible.

I'd be happy to release our bundler as a separate module if there's interest from people.

[eventualbuddha]

I'm willing to bet this wouldn't handle all cases well. What happens with
cycles? Would something like Esperanto's bundler work for you?
On Wed, Jul 8, 2015 at 2:04 PM Zibi Braniecki notifications@github.com
wrote:

I wrote a very minimalistic es6 bundler as a plugin for babel.

You can find the source code here:
https://gist.github.com/zbraniecki/649e0390d57ac353494d
(it requires a small patch to babel that landed here: #1951
#1951 and should be in the next
release)

It looks like this:

It turns sth like this:
./src/lib/core.js:

export function foo() {
}

./src/runtime/web/index.js

import { foo } from '../../lib/core';

into:

'use strict';

(function (global) {
const modules = new Map();
const moduleCache = new Map();

function getModule(id) {
if (!moduleCache.has(id)) {
moduleCache.set(id, modules.get(id).call(global))
}
return moduleCache.get(id);
}

modules.set('lib/core', function () {
function foo() {
}
return { foo };
});

modules.set('runtime/web/index', function () {
const { foo } = getModule('lib/core');
});
})(this);

It allows us to remove webpack from the toolchain (which is important
because webpack cannot work on not-transpiled es6 code) and gives us a very
readable output because the modules look as close to the original files as
possible.

I'd be happy to release our bundler as a separate module if there's
interest from people.

—
Reply to this email directly or view it on GitHub
#1681 (comment).

[zbraniecki]

No support for cycles yet. Didn't need so far

[jamesplease]

@samccone, clarifying question. Do you mean all dependencies including third party libraries? Or just 'internal' dependencies?

In other words, if my point of entry file has:

import $ from 'jquery';
import utils from './utils';

Would you want the flag to bundle up both jQuery and utils, or just utils?

[samccone]

both @jmeas :)

[jamesplease]

k, cool. 👍

[sebmck]

Closing this and marking it as revisit for something to look into in the future. I'll delegate this to rollup for the timebeing.