Granular compress option

[mmkal]

I think it'd be great to be able to do this:

package.json

{
  "name": "foo",                      // your package name
  "type": "module",
  "source": "src/foo.js",             // your source code
  "exports": {
    "require": "./dist/foo.cjs",      // used for require() in Node 12+
    "default": "./dist/foo.modern.js" // where to generate the modern bundle (see below)
  },
  "main": "./dist/foo.cjs",           // where to generate the CommonJS bundle
  "module": "./dist/foo.module.min.js",   // where to generate the ESM bundle
  // note the 'min' here 👇👇👇
  "unpkg": "./dist/foo.umd.min.js",       // where to generate the UMD bundle (also aliased as "umd:main")
  "scripts": {
    "build": "microbundle",           // compiles "source" to "main"/"module"/"unpkg"
    "dev": "microbundle watch"        // re-build when source files change
  }
}

Then expand the --compress option to allow a regex. So, if you run --compress min it's saying "Compress the outputs that contain the string min". In the above case, it'd only minify the module and unpkg outputs.

This'd be useful to allow node users to use unminified code but browser users to use minified etc. It could be made to be non-breaking by making --compress true and --compress false special cases to enable/disable all.

[rschristian]

This'd be useful to allow node users to use unminified code but browser users to use minified etc

This in particular would be better served by running Microbundle twice -- target affects the output beyond the default compress value.

[mmkal]

This'd be useful to allow node users to use unminified code but browser users to use minified etc

This in particular would be better served by running Microbundle twice -- target affects the output beyond the default compress value.

@rschristian related to that - are there any docs around that? Does --target node mean it can't be used in web contexts for any reason?

Either way, that's just one example use case. In general there are lots of reasons consumers might not need or want to deal with (pre-)minified code.

[rschristian]

are there any docs around that?

Not to my knowledge, might be good to have something in the future though.

Does --target node mean it can't be used in web contexts for any reason?

Depends on the input really. If one were to use Node built-ins (fs, url, etc), then they'll run into issues as those are not available in a browser context without some polyfill to make sense of them (and --target node won't warn you). Past that, you can also run into some syntactic issues as the target version for Node right now is Node 12 (perhaps should be bumped to 14, but I digress). Bundles built for Node (12) will not see the same browser support that --target web will get you.

However, as Node 12 is roughly equivalent to ES2019, it's somewhat unlikely outside of enterprise that you'll actually have issues loading that Node-targeted bundle in a browser.

Either way, that's just one example use case.

Yeah, absolutely, just wanted to address the Node + web thing. Personally, I'm on the fence over it, as I'm not enthusiastic about additional complexity (in both the flags and source) when it's easy for users to simply have two build scripts.