Open taras opened 1 year ago
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
@taras what does importing svg mean? Like on-the-fly transpilation of a .svg
to a ESM representation?
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.
Hm.... looks like a non-standard Webpack extension
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.
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.
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
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:
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
.
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.