Allow code components to import from npm packages

Up until now, the XB team has been following a pseudo-scrum/pseudo-kanban process, but we're now shifting into more conventional scrum. We started a new 2-week sprint last Thursday (Jan 16). I'm tagging our current sprint's issues for visibility. This one I'm tagging with "spike" rather than "sprint", because our goal isn't to complete the implementation of it this sprint, but to figure out if the proposed approach is viable or if we need to change it in some way.

@effulgentsia do you have something in mind to parse the JS and flag the imports - e.g. an AST/parsing library?

If not, I can look into something like babylon, which is the parser used by babel.

Does @jspm/generator not do that? The CLI's jspm link can be pointed to an HTML file, but not sure whether it's only the CLI that can parse or if the generator library can as well.

Babylon seems fine if we need a separate parser. In case it helps, we'll be using https://swc.rs/docs/usage/wasm to compile. I don't know if it has any API to access the imports, but perhaps it makes sense to parse the compiled JS to find the imports, in which case something lightweight like Acorn might suffice?

I have a POC of using babylon to parse out imports here

Paste this in to the text box

import * as Accordion from "@radix-ui/react-accordion";

export default function MyComponent() {
  return (
    <Accordion.Root>
    </Accordion.Root>
  )
}

I'll continue with this tomorrow by adding in jspm/generator code to see if we can get an importmap

Ah, this is literally point 1 in the issue summary. But I'm surprised that #3499927 was created without taking this into account and this issue's title doesn't convey that it's a spike for future functionality and it doesn't link that issue. 😅

1. For now, we can hard-code a CDN (e.g., https://esm.sh/) to map them to. In the future, we can make that CDN configurable.

Blindly trusting a single external site is a serious risk: performance, reliability but certainly also security! Especially when they're maintained by a single person. I'd not want to do this unless we at minimum do https://developer.mozilla.org/en-US/docs/Web/Security/Practical_implemen...

But apparently supporting this for import maps is pretty much brand new: https://jspm.org/js-integrity-with-import-maps, published August 5, 2024, released in Chrome 127. But that's only got 78.7% global support right now; it's not supported at all in Firefox for example: https://caniuse.com/mdn-html_elements_script_type_importmap_integrity

Removing the security tag because it makes this issue listed on the project page as as a publicly disclosed security issue which this isn't since the security implication has to do with what's being done in this issue.

Removing the security tag because it makes this issue listed on the project page as as a publicly disclosed security issue which this isn't since the security implication has to do with what's being done in this issue.

🤯 Since when is that the case?! 🤪

https://github.com/mozilla/standards-positions/issues/1010 is the issue to follow for updates on Firefox's plans to support importmap integrity.

#7 ✨ Allow code components to import from npm packages Active :

But I'm surprised that #3499927 was created without taking this into account and this issue's title doesn't convey that it's a spike for future functionality and it doesn't link that issue. 😅

I would recommend that we land ✨ Config entity for storing code components Active with its current scope to unblock the handful of issues it blocks. Given that this issue is in the spike stage, I would also recommend waiting with creating additional issues or adding relationships to existing ones before we know what our approach will be. I'm happy to update 🌱 [Meta] Plan for code components Active once we're there.

The POC in #6 ✨ Allow code components to import from npm packages Active is really cool! 👏🏻

I have a suggestion to also explore this from a different angle. Instead of parsing imports from the code, like it's done in #6 ✨ Allow code components to import from npm packages Active , what if we maintained a list of supported packages, and designed UI to add import statements to a code component? We could even go as far as showing/hiding the import statements in the code editor, e.g. displaying them in a collapsible, non-editable area.

What does this approach get us? Most importantly, it addresses Wim's concerns ( #7 ✨ Allow code components to import from npm packages Active ) about performance, reliability, and security. A curated list of packages that we can include in our app's bundle. (We really need to start thinking about code splitting, but let's leave that as a future problem to solve. 🙂)

Additionally, it might even be a nice UX to be able to browse a list of quality, recommended packages to use in your components. It is not the freedom to use anything from npmjs.org, but this might be fine for the target audience of code components. Radix Primitives would be a great start, they're commonly used, even tools like v0.dev generate code that (indirectly) depends on them. We could then open this up for modules, as a new extension point, to provide new sets of packages.

#12++ … and that ties in elegantly with your proposal at #3499933-18: Storage for CSS shared across in-browser code components (and PageTemplate config entities in the distant future) → to introduce config-defined in-browser code libraries — that "list of quality, recommended packages" could be defined entirely as one or more in-browser asset libraries.

P.S.: literally yesterday:

The specification for this has landed in HTML and the implementation landed in Chromium and WebKit.

— https://github.com/mozilla/standards-positions/issues/1010#issuecomment-...

Related: ✨ Add an API for importmaps Active — being worked on by @larowlan :)

I have a POC going in this commit

The issue is we can't use this import map in the current page because you can't change the import map in the current page at run-time
But I guess if we make the preview component use an iframe, we could inject the import map into there.

Here's a video. I think this is enough to conclude the spike.

Findings:

• Parsing of HTML in @jspm/generator wasn't working because it doesn't like JSX
• I was unable to get acorn + acorn-jsx to parse the example component (below)
• Using babylon (the parser under the hood of babel) gave us the nice advantage of syntax checking

Example component text I was parsing

import * as Accordion from "@radix-ui/react-accordion";

export default function MyComponent() {
  return (
    <Accordion.Root>
    </Accordion.Root>
  )
}