search

Moddable-OpenSource / moddable

Tools for developers to create truly open IoT products using standard JavaScript on low cost microcontrollers.
http://www.moddable.com
1.34k stars 236 forks source link

Module resolution strategies for a multi-platform framework #289

Closed dtex closed 4 years ago

dtex commented 4 years ago

Hi all, I'm working on a framework that will run in XS, node.js, the browser or whatever. There are many interdependent modules. I've discovered that if I namespace each module in the manifest.json with my framework name, then set up an npm organization with the same name and publish each module separately under that organization, then I can resolve modules for XS or node.js. For example:

import myModule from "@myFramework/myModule";

Will find the @myFramework/myModule key in the framework's manifest.json when building in XS and will resolve to ./node_modules/@myFramework/myModule when running in node.js.

It works, but the downside is that each module must be published as a separate npm package. This is manageable with a Lerna mono-repo, but it does add a layer of complexity that I'd just as soon do without. Also, this doesn't really solve things for the browser.

I just want to make sure I'm not trying to solve a problem that someone has already figured out.

dtex commented 4 years ago

Ah, nevermind. It looks like it's a problem that hasn't been solved yet:

https://github.com/WICG/import-maps

phoddie commented 4 years ago

FWIW - within Node, import maps may be a solution (the last time I read the specification, it provided a lot of flexibility). Within the work of TC53, and surely within the Moddable SDK, the Module Map argument to the Compartments constructor (part of the Secure ECMAScript) work can give similar functionality for some scenarios, though it isn't intended as a substitute for import maps. That said, Node runs on devices with much more power, so ideally the default module paths/specifiers work as-is for embedded devices and any remapping happens in Node, where the impact is small by comparison.

dtex commented 4 years ago

I agreed re: keeping the heavy lifting and shims in node.js.

I'm looking at some experimental import-maps implementations for node. That should be sufficient for now since I'm really only using node.js for unit testing and there are no implementations of the IOCP yet.

Thanks for looking at this issue.