Custom output formats?

[mbostock]

I had to do something a lil’ dirty in d3-bundler. I call bundle.generate with iife format and then mangle the resulting code:

function patch(code) {
  if (code.slice(0, 37) !== "(function (exports) { 'use strict';\n\n") throw new Error("unexpected output");
  if (outro = code.slice(-26) !== "\n})((this.exports = {}));\n") throw new Error("unexpected output");
  try { var version = require(path.resolve(entry, "../package.json")).version; } catch (ignore) {};
  return "!function(global, exports) {\n"
      + "  \"use strict\";\n"
      + "\n"
      + code.slice(37, -26)
      + (version ? "  exports.version = " + JSON.stringify(version) + ";\n" : "")
      + "\n"
      + "  if (typeof define === \"function\" && define.amd) global." + argv.name + " = exports, define(\"" + argv.name + "\", [], function() { return exports; });\n"
      + "  else if (typeof module === \"object\" && module.exports) module.exports = exports;\n"
      + "  else global." + argv.name + " = exports;\n"
      + "}(this, {});\n";
}

I do this because I have “special” requirements for my UMD module, as D3 is a library:

• I want to generate a named AMD module, not an anonymous one.
• I want to export a global even if AMD is available (but not with CommonJS).
• I want to automatically pull the version number from the package.json.

My hack’s not too bad since the iife format is pretty simple, but do you think this is the right way to do it?

[Rich-Harris]

Have wondered about this. Can definitely see the value in it. The reason it hasn't happened already is that it means exposing more of Rollup's guts than is ideal, at least as currently implemented – so we'd probably need to spend a bit of time finessing the API. (The really tricky part isn't the format-specific code that wraps the bundle as much as the identifier renaming logic, which differs according to whether the output is an ES6 module.)

In the shorter term, we can get two out of three:

• you can use options.moduleId to generate a named AMD module
• rollup-plugin-replace can take care of the version number

What if we added an option to generate a global in an AMD environment? I've had need for similar things in the past myself, it's probably not that esoteric a requirement.

[Victorystick]

Another option is (could be) to use rollup-plugin-json and

main.js

export { version } from './package.json';

[Rich-Harris]

Right now the plugin only exports default, so you'd need to import all of package.json and export version – I've opened rollup/rollup-plugin-json#1 because I think that export { version } from './package.json' should work.

[Rich-Harris]

Released an updated version of the JSON plugin – it now supports export { version } from './package.json' and doesn't unnecessarily include the rest of the file.

[mbostock]

Wouldn’t importing a JSON file (as opposed to another ES6 module) such as package.json make my ES6 module incompatible with any non-Rollup loader?

Seems like a more compatible approach would be to auto-generate an ES6 version module as part of the build process. Something like:

node -e 'process.stdout.write(\"var version = \\\"\" + require(\"./package.json\").version + \"\\\"; export * from \\\"../index\\\"; export {version};\");' > build/bundle.js && rollup -o build/d3-arrays.js -- build/bundle.js

[Rich-Harris]

Yes – tool-specific stuff in distributed code is a scourge, whether it's a Rollup plugin, a Browserify transform, a Webpack loader, or whatever. I've been bitten by this on a number of occasions and I'm determined to avoid there ever being a need for e.g. a "rollup" field in package.json.

In most of my packages I've been doing exactly what you suggest – generating an ES6 build (alongside the UMD build) at publish time, and pointing to it with jsnext:main, so my package.json looks something like this:

{
  ...,
  "main": "dist/my-package.umd.js",
  "jsnext:main": "dist/muy-package.es6.js",
  "scripts": {
    "build": "rollup -c -f umd -o dist/my-package.umd.js && rollup -c -f es6 -o dist/my-package.es6.js",
    "prepublish": "npm run build"
  }
}

(In this example, the -c part of rollup -c means 'use the configuration in rollup.config.js'.)

There's some residual confusion over what the exact meaning of jsnext:main should be (jsforum/jsforum#5), but this approach has been working pretty well for me.

[ayushmad]

I am not sure if this is helpful. But to bring in the package version this is what i do.

In my index.js[entry file] I do.

export var version = publishedVersion | '0.1.12'; 

and in my bundler which uses rollup I do this.

var _package = require('package.json'),
      rollup = require('rollup');
rollup.rollup({
  // Options
}).then({
  bundle.generate({
     intro: 'var publishedVersion=' + _package.version;  // Passed the package Version in the intro code
   });

Hope this helps.

[mbostock]

Thanks for the help. I’ve migrated all the D3 modules over to using Rollup directly rather than using d3-bundler. I’ve also decided to not inline external dependencies in the default build, since that makes it easier to compose D3 modules using basic concatenation without duplicating code. I’m only planning on inlining when making a monolithic build (i.e., d3.v4.js). My guess is I can probably use Rollup directly for that, too, and eliminate d3-bundler entirely. So, thanks!

[Victorystick]

We may want to think about how to integrate other module formatters. If we add support for it, we could emphasise that it's an experimental API that could change?

The really tricky part isn't the format-specific code that wraps the bundle as much as the identifier renaming logic, which differs according to whether the output is an ES6 module.

@Rich-Harris The same applies for other output formats, such as SystemJS. It too has direct access to imported values. Rollup doesn't currently support SystemJS, and probably won't for some time. Regardless, I've been trying to promote writing direct instead of es6 in the code. In the example below (from src/Declaration.js), we render variable names differently for es6 (direct access) and every thing else (indirect access through an object).

    render ( es6 ) {
        if ( es6 ) return this.name;
        if ( !this.isReassigned || !this.isExported ) return this.name;

        return `exports.${this.name}`;
    }

We could allow a format to specify whether they have direct or indirect access, and keep this code as is.

[snuggs]

A little stale. We can close this correct? @Victorystick