Research on tools for generating importmaps

[taras]

• List of resources created by @domenic
• JSPM CLI CLI for generating importmaps
• JSMP Generator
• Importmaps reference implementation
• Rollup plugin for converting urls to relative packages rollup-plugin-import-maps
• Going buildless blog post
• import-map-deployer service for hosting import maps
• importly - generate import map from package-lock.json
• importmap-node-module - Generate import map file with mappings corresponding to node esm resolution algorithm. It can make code dependent on node module resolution executable in a browser.

[taras]

npx jspm@latest link --map plugins/manifest-manager-backend/src/service/index.html -o test.html -p nodemodules -r backstage-plugin-plugin-a=backstage-plugin-plugin-a -r backstage-plugin-plugin-b=backstage-plugin-plugin-b

Fails to import svg with the following error Error parsing file:///Users/tarasmankovski/Repositories/backstage/importmaps-poc/node_modules/@backstage/core-components/dist/components/EmptyState/assets/createComponent.svg:1:4853

[cowboyd]

@taras what does importing svg mean? Like on-the-fly transpilation of a .svg to a ESM representation?

[taras]

Here is an example

import missingAnnotation from './components/EmptyState/assets/missingAnnotation.svg';

Webpack would put the file into the public directory and return a URL to that file. In our case, we need to generate a URL without attempting to treat it as a JS file.

[cowboyd]

Hm.... looks like a non-standard Webpack extension

https://github.com/thefrontside/backstage/blob/master/packages/core-components/src/components/EmptyState/EmptyStateImage.tsx#L68

In order to use this technique, the plugins do need to export valid JavaScript, so it would need to be added to the build step like the TypeScript compilation, or find another way to do it.

[taras]

I'm not sure that's true. I'm pretty sure it's just using a loader that loads static files. You can see that it's just a regular svg file https://github.com/thefrontside/backstage/blob/master/packages/core-components/src/components/EmptyState/assets/createComponent.svg

I'm unsure if it's a plugin that comes with webpack, but it's pretty common.

[Rugvip]

Yep just a plain resource loader, https://github.com/thefrontside/backstage/blob/5b381397e5b28e6371be94442ee559b4abb3fe69/packages/cli/src/lib/bundler/transforms.ts#L149.

This is a custom Webpack extensions 😁 https://github.com/thefrontside/backstage/blob/5b381397e5b28e6371be94442ee559b4abb3fe69/packages/cli/src/lib/bundler/transforms.ts#L115-L137

[cowboyd]

By non-standard, I mean something that your browser's JavaScript engine does not understand. For example, it is also very common to import .css files too, but at the end of the day, ES modules imported into the browser need to be ES.

Today, Webpack is a kitchen sink that does:

• transpilation with TypeScript + custom extensions (let's call it JS++)
• bundling
• module resolution

Using import maps severs the latter two responsibilities and offloads them onto the browser, which I think is a major plus long term, but it does mean we still need to handle the first responsibility somehow.

In this particular case, my personal preference would be to find a different way to do it (Something about publishing an ES module that assumes a path on a web server feels wrong) but in the general case, we would need to treat cases like these just like we would TypeScript: before publishing it needs to transpiled to standard JS with a tool like babel or esbuild.

[taras]

We have control over the bundles generated by Backstage CLI. We could create a new bundle that would include only the modules that browsers understand.