How to get unbundled cjs/es modules as in version 0.4.4?

[gamtiq]

First of all I would like to thank for the excellent tool!

Before version 0.5.0, building with cjs and es format produced unbundled modules with required/imported dependencies (i.e. output of entry modules didn’t contain code of its dependencies).
Is it possible to get the same result in the current version (0.11.0)?

[ForsakenHarmony]

You dependencies should not get bundled

Which command are you running to build(/bundle) your library?

[tunnckoCore]

@gamtiq 0.4.4? That's pretty old at first and it probably was wrong behvaior.

Anyway, you should be able to use --external (comma-separated list) for this, or just add them in dependencies or peerDependencies. It's general practice when you want to bundle them to put them in devDepdendecies, since most similar tools automatically get deps and peerDeps and put them as "external" (so they won't get bundled).

[developit]

Yup! devDependencies get bundled, dependencies & peerDependencies don't.

[tunnckoCore]

devDependencies get bundled

It's not exactly correct to say that. You get bundled the dependencies that your code uses - unless they are in deps & peerDeps, it's not bundling all devDeps. You can put your dependencies wherever you want - e.g. optionalDependencies.

Anyway, just a bit clarification for total newcommers.

[gamtiq]

The talk is about local dependencies (not from npm).
The following example should clarify the case.

Source code

package.json

{
  "name": "some-lib",
  "version": "1.0.0",
  "main": "src/index.js",
  "scripts": {
    "build-commonjs": "microbundle build \"src/*.js\" --output dist/commonjs --format cjs --strict --no-compress",
    "build-esm": "microbundle build \"src/*.js\" --output dist/es-module --format es --no-compress"
  },
  "devDependencies": {
    "microbundle": "0.11.0"
  }
}

src/a.js

export function a() {
}

src/index.js

import { a } from './a';

export function b() {
    return a();
}

Result for microbundle 0.4.4

After running npm run build-commonjs you have got the following output.

dist/commonjs/a.js

'use strict';

function a() {}

exports.a = a;
//# sourceMappingURL=a.js.map

dist/commonjs/some-lib.js

'use strict';

var a_js = require('./a.js');

function b() {
    return a_js.a();
}

exports.b = b;
//# sourceMappingURL=some-lib.js.map

You can see that local dependency is not bundled but imported.
The same is true for npm run build-esm.

Result for microbundle 0.11.0

After running npm run build-commonjs you have got the following output.

dist/commonjs/a.js

'use strict';

function a() {}

exports.a = a;
//# sourceMappingURL=a.js.map

dist/commonjs/some-lib.js

'use strict';

function a() {}

function b() {
  return a();
}

exports.b = b;
//# sourceMappingURL=some-lib.js.map

You can see that dependency from a.js is bundled into some-lib.js.
The same is true for npm run build-esm.

Versions 0.5.0+ have similar output.

Is it possible to get for current version of microbundle the same result as for version 0.4.4?

[tunnckoCore]

Don't think so.

That totally not making sense to me, sorry. Seems like bug in that 0.4.4 version I guess.

What you want is not bundling but building, so you can just use Babel for this which outputs the same file structure but transpiled.

Why would you want such output? Why would you use microbundle or anything built on top of Rollup or Webpack when you don't want everything to be bundled in one file?

Recent versions of Rollup support that though (or similar thing, didn't tried it yet) with preserveModules, but I don't see the point at all.

[Andarist]

One reason for preserveModukes is to still benefit from tree shaking and rollup plugin processing. The use case is niche but it is there.

Other thing than preserveModules is ability to output multiple entry files - and the use case for this is to bundle everything as flat as possible, but create multiple public entry points with code shared between them by automatically created chunks. It exposes what we want to be public, but hides everything that is supposed to be private

[gamtiq]

Why would you want such output? Why would you use microbundle or anything built on top of Rollup or Webpack when you don't want everything to be bundled in one file?

The short answer is simplicity.
microbundle allows to bypass complex configuration of build tools (e.g. Babel, Rollup, webpack etc).
For me the behavior of version 0.4.4 makes sense. Using one tool (microbundle) I can get transpiled but not bundled CommonJS and ESM builds and bundled UMD build.

[ForsakenHarmony]

if you don't want bundling you might just want to use babel with babel-preset-env

[Andarist]

@ForsakenHarmony this would force @gamtiq to create multiple babel tasks (1 for ESM, 1 for CJS) and he'd still probably have to use rollup/microbundle to output UMD. Gains from using microbundle in this case are questionable - but it's nice to have a single tool that can do its job with 0 config.

But even besides that, there are reasons for bundling into multiple entry points. https://preconstruct.tools/guides/when-should-i-use-multiple-entrypoints

For example in emotion we have 2 entry points for one of packages - @emotion/styled and @emotion/styled/base. This is because that main entry looks like this:
https://unpkg.com/browse/@emotion/styled@11.0.0-next.3/dist/styled.browser.esm.js

It just adds some convenience stuff onto /base entry - but with a babel plugin we actually rewrite imports and call sites to use that /base directly.

In this particular example benefits of using rollup are not as apparent, but in the case of redux-saga becomes more clear:
https://unpkg.com/browse/@redux-saga/core@1.1.3/dist/
There are 2 entry points - redux-saga and redux-saga/effects - and they share common (private) code which gets put into auto-generated chunks (those io-*.js in here).

[ForsakenHarmony]

If it's just about having multiple entrypoints, you can currently do that

We have it setup for microbundle itself

https://github.com/developit/microbundle/blob/master/package.json#L11

(but I guess that's cjs only, I'm not entirely sure how well it works with multiple formats)

[tunnckoCore]

The thing is that all this is already totally different behavior and new feature to comment (not bundling at all even local deps).

I'm guessing that @gamtiq can currently do --external ./a.js and for all other local files. It's a bit to much but... that's for now.

[marvinhagemeister]

Reading the through comments here, it sounds very much like microbundle doesn't fit into the problem space the original poster is looking for. microbundle originated from the preact repo where we were looking for ways to make our customized build pipeline reusable. As the name microbundle implies we do bundle the code for performance reasons for preact.

Supporting non-bundled code is a non-trivial task. My understanding is that there may have been some accidental behavior like that possible in a very early version. As far as I'm aware it was not a planned feature, hence the reliance on a bundler like rollup at the core.

Nonetheless it's an interesting use case. I'm sure the team is happy to review any PRs or give guidance of the code in this repo if needed. I don't think it makes much sense for the microbundle team to work on that, because it's just a thin wrapper around rollup with some pre-configured plugins. If rollup or some plugin allows for such a feature to be easily implemented, it would be worth to check that out.