Support for "package.json browser" style file replacement/removal within modules?

[andyredhead]

Hi,

It's clear that the purpose of import-maps is to enable loading complete ESM modules in a browser context.

My question is whether there is anything in import-maps that facilitates substituting or supressing files within a module (the goal being to avoid modifying the contents of a package sourced from npm)?

(I suspect not but hoping for clarification)

I've been "tinkering" with a "bunder-less" approach to using ESM modules in a browser by using a combination of a hand written import-map and some webserver jiggery-pokery (to deal with extensionless references to modules, top level index.js within modules etc.).

It's been hanging together surprisingly well :)

Until...

I came across modules in npm that try to accommodate running in both server side node.js and browser contexts via the "browser" entry in package.json, which end up needing to either use some different files than those referenced within the JavaScript source code or to completely remove a reference to a file from the source code delivered to the browser.

For example, in npm module @loaders.gl/worker-utils (part of the @deck.gl data visualisation suite) there is the section:

  "browser": {
    "child_process": false,
    "module": false,
    "path": false,
    "fs": false,
    "./src/lib/node/worker_threads.ts": "./src/lib/node/worker_threads-browser.ts",
    "./dist/es5/lib/node/worker_threads.js": "./dist/es5/lib/node/worker_threads-browser.js",
    "./dist/esm/lib/node/worker_threads.js": "./dist/esm/lib/node/worker_threads-browser.js",
    "./src/lib/node/require-utils.node.ts": "./src/lib/node/require-utils.browser.ts",
    "./dist/es5/lib/node/require-utils.node.js": "./dist/es5/lib/node/require-utils.browser.js",
    "./dist/esm/lib/node/require-utils.node.js": "./dist/esm/lib/node/require-utils.browser.js",
    "./src/lib/process-utils/child-process-proxy.ts": false,
    "./dist/es5/lib/process-utils/child-process-proxy.js": false,
    "./dist/esm/lib/process-utils/child-process-proxy.js": false
  },

NOTE: I don't think there is anything wrong with this package, it's just a good example of a non-trivial JavaScript module.

Using redirects on the server side makes it possible to deal with file substitutions such as:

"./dist/esm/lib/node/worker_threads.js": "./dist/esm/lib/node/worker_threads-browser.js",

(no module source code modification required)

The "ignore file" instruction is causing me problems, i.e. lines like:

"./dist/esm/lib/process-utils/child-process-proxy.js": false

If I manually comment out the line in the module top level index.js file that references "child-process-proxy.js", all is well. However, my goal is to use the npm provided modules "as-is" (changing the npm provided source code defeats this objective).

Are there any features in import-maps that facilitate:

• Modifying how individual files within a module are loaded (i.e. loading a browser friendly js file, rather than a file that uses node.js specific libs)
• Telling the browser to ignore references within loaded JavaScript files to specific files
  ?

Thanks, Andy

[chase-moskal]

hey @andyredhead,

i was just looking into the "browser" field spec, which appears to be a defacto community standard, supported by bundlers like browserify, webpack, jspm, etc, however it is not documented in the npm docs.

this "browser" field concern may be more in scope for import map tooling, such as the tool that i maintain called importly that generates import maps, rather than the spec.

i have a hunch we may be able to add support for this in importly — import maps allow us to remap individual files — however a potential snag comes up with the ignore rules, eg "./example.js": false, where i suspect we may need to deploy some kind of funky hack like referring to an empty dud module or something like that..

importly is due for an overhaul anyways, to implement the imports/exports package.json standard, so we may as well throw support for the browser field into the mix as well.. reach out if you'd like to collaborate on it 😎 👍

[andyredhead]

Hi @chase-moskal , thanks for your reply. I'll take a look at importly (and resolve.exports).