Support "buildless" vanilla js / import maps

[Risto-Stevcev]

Introduction

Support import maps with react native (see browser support).

Details

With the latest improvements in Node.js and ES6 modules, there 's a new way of developing javascript projects that can avoid a lot of the complexity that often comes with building and setting up a modern javascript project.

The idea is to use import maps with Node.js for your application, so that if you only need vanilla js, you can avoid build steps entirely. The import maps are usually mapped either to node_modules as a relative path, or to a url from unpkg/jspm. Note that only npm modules that support ESM work, but there are a lot that do and it will continue to grow.

Discussion points

• Although import maps are new, they might still be used for a new project that isn't interested in targeting older browsers. Desktop apps built in a webview (Electron/Tauri/NW.js/Cordova) can also be written like this right now, since they can bundle a compatible browser version.
• I would be looking towards forward-compatibility. Bundlers could become less common to use, devs will want to avoid complexity, new languages and tools will likely emerge, etc.
• Can this impact the architectural decisions of RN? or is it compatible with Hermes?
• Might be related to this issue: facebook/react-native#37065
• For the JSX issue, it could be done with babel. Devs also might want to avoid all processing steps entirely including JSX and instead use something like react-hyperscript, since React works with import maps.
• This is still really early stages, and a lot of npm libraries don't compile for ESM. But I think that the number that do is likely to continue to grow so that people can move past the ES6/CommonJS compat issues (type: module/.cjs/.mjs/await import).

[huntie]

Hi @Risto-Stevcev, this is interesting! What's the main use case you see this enabling for a React Native app today?

• In native apps, we build a JS bundle to run locally on the device and our current build tooling is oriented around this. In this bundler model, we offer config hooks such as redirectModulePath which can achieve the essence of this functionality — redirecting imports to a desired target module.
• In React Native for Web, the browser environment is available (including support for <script type="importmap">).
  • Related note (and probably the relevant missing piece): We're considering supporting externals in Metro in future. This would allow certain module specifiers to be excluded from bundling, meaning these imports would be left alone in the resulting bundle — which would then work with import maps implemented by browsers.

---

Note for Metro maintainers: WICG/import-maps is distinct from Package Imports — the latter is considered by runtimes/bundlers interpreting package.json only and supports private import specifiers with a # prefix.

[Risto-Stevcev]

Hi @huntie,

I'm really excited about import maps because I think it provides a unique and low-effort way of reusing, securing, or even optimizing code.

For example, say you make a DateTimeRangePicker that uses this DateTimePicker library for React Native. You just implement your standard implementation as usual, using the DateTimePicker for the to/from dates, and validating that the range is acceptable (ie: the to date is earlier than the from date), and ship it. There's a problem though, because what if:

1. DateTimePicker doesn't have the right UX for users of your library
   • The magic with import maps from a library consumer is that users of the library can now easily swap the internally used DateTimePicker for your own custom DateTimePicker that better matches your UX/business needs, fixing the picker and reusing everything else.
2. DateTimePicker has a security vulnerability
   • You don't have to wait upstream for someone to patch it, blocking your progress -- just use import maps to shim in your security fix.
3. DateTimePicker isn't as fast as it could be
   • It maybe uses a slow algorithm, which you could patch. Or even replace a slower library with a faster one that uses a similar API (ie: underscore -> lodash)

So it's not just react native -- I think this is a low effort way of potentially solving a lot of challenges because import maps allow you to contextualize the imports, effectively allowing you to dependency inject your own implementation of any module without having to fork your own custom copy of the library.