Feature: Allow use of modules with imports outside of livecodes

[aehlke]

Type of feature

✨ Feature

Current behavior

No response

Suggested feature

livecodes has useful import features such as skypack: and jsdeliver.gh: prefixes. However these are only runnable inside of livecodes, it seems. It would be great to have a way to reuse these files in other build systems, I'm not familiar enough with JS to know how to make this "cross-platform"

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Contributing Docs

• I agree to follow this project's Contribution Docs

[hatemhosny]

custom specifiers e.g. import {v4} from 'skypack:uuid' are not valid JS.
Even bare module import is not valid ESM syntax e.g. import {v4} from 'uuid'

These are enabled in LiveCodes for convenience.
ESM imports need to be valid URLs. So 'skypack:uuid' becomes 'https://cdn.skypack.dev/uuid'

However, if you use that in a LiveCodes project and export it (e.g. to HTML file), it should still work.
This is achieved using import maps, where you can use aliases for imports.

something like this is added to the page:

<script type="importmap">
{ "imports": {
    "skypack:uuid": "https://cdn.skypack.dev/uuid"
  }
}
</script>

This even works if you export to CodePen. The full URL is used in the import.

Module resolution in LiveCodes is described here: https://livecodes.io/docs/features/module-resolution
And the list of CDN specifiers can be found here: https://livecodes.io/docs/features/module-resolution#cdn-providers

What are you trying to achieve that is not working? Can you share an Example?

[aehlke]

In my suggestion here #443 I tried to give a more concrete idea for solving some pain point of introducing import maps and integrating them into other work/deployments - such that these conveniences can be used during development easily and flexibly exported in the current ways LiveCodes supports + in a "fully baked" output I propose that would render

Ideally code written for/in LiveCodes could be more easily used in other contexts, which currently means not using the import map conveniences (or adopting the import maps into the rest of the prod deployment). Perhaps there's a way to have an output option where for example it defines an NPM-compatible package with the dependencies defined such that other tools know how to pull them. But as an alternative to this approach, I wrote the above idea