Using rollup to generate import-maps

[ashubham]

Has anyone explored building a rollup plugin to generate import-map as an output ?

This would move us closer to an unprocessed shipped code. Also, help in some development workflows.

[isidrok]

Hi,
I have been working on one for resolving different packages (from a monorepo) at runtime using SystemJS imports-map implementation.

So far I like it very much since I can build different projects separately when any of them changes and only the import-map needs to be updated allowing for an efficient caching strategy and independent releases. It requires some additional tooling but its pretty straightforward.

Given two projects form and app the usage is something like:

// app/src/index.js
import {form, formField} from '@x/forms';
// ...
export default app;

// forms/rollup.config.js
plugins: [
  importMap({
      'src/index.js': '@x/forms',
  })
]

// app/rollup.config.js
external: ['@x/forms'],
plugins: [
  importMap({
      'src/index.js': '@x/app',
      'src/some-public-module.js': '@x/some-public-module'
  })
]

After building both projects two json files are generated:

// dist/forms/map.json
{
   "@x/forms": "forms/index.asdf1234.js"
}

// dist/app/map.json
{
   "@x/app": "app/index.asdf1234js",
   "@x/some-public-module": "app/some-public-module.asdf1234.js"
}

resulting in a map from package names to rollup generated chunks.

Finally a custom node module generates the import-map by merging all individual map.json files after each build, and offers a middleware for the development server:

// dist/import-map.json
{
  "imports":{
     "@x/forms": "forms/index.asdf1234.js",
     "@x/app": "app/index.asdf1234js",
     "@x/some-public-module": "app/some-public-module.asdf1234.js"
   }
}

[daKmoR]

wouldn't it be more like that rollup should take in an "import map" and use it to resolve the paths?

That way you could control which files actually are going to end up in your bundle.
Useful for example:

• if you have nested packages but one version would be enough
• to fix a dependency with a local fork (hopefully temporarily)

[domenic]

Just wanting to let people know that I have a pull request up at #147 to discuss all the tooling we've seen so far in the README. Also, I opened a new issue #146 to provide a general discussion space, in lieu of this issue + #60. So I'll close out this issue, but see you in #146!