Launching main ESM module with `search` and `hash`

[LiviaMedeiros]

What is the problem this feature will solve?

We can provide query and hash in ESM imports:

// 1.mjs
import './2.mjs?key=value#hash';

// 2.mjs
const { search, hash } = new URL(import.meta.url);
console.log({ search, hash });

$ node 1.mjs
{ search: '?key=value', hash: '#hash' }

However, AFAICT there is no way to provide them directly to main module:

$ node 2.mjs
{ search: '', hash: '' }

What is the feature you are proposing to solve the problem?

Command line option(s) to provide search and hash, e.g.

$ node 2.mjs --import-search="?key=value" --import-hash="#hash"
or
$ node 2.mjs --esm-appendix="key=value#hash"

What alternatives have you considered?

Right now we can do this with empty script:

$ node --input-type="module" --import="./2.mjs?key=value#hash" < /dev/null
{ search: '?key=value', hash: '#hash' }

$ node --import="./2.mjs?key=value#hash" --eval=";"
{ search: '?key=value', hash: '#hash' }

Which

• potentially will mess up with import.meta.isMain
• messes up with process.argv because process.argv[1] will contain first argument instead of path to 2.mjs
• requires to provide URL, i.e. to percent-encode special characters, to start relative paths with . or .., and to use forward slashes on Windows

[aduh95]

There's of course the possibility of doing node --input-type=module -e 'import "./2.mjs?key=value#hash"', although it would also not help with import.meta.main and the other things you listed.

I think that's something Loader Hooks API can already provide, and for that reason, I don't think we should add flags for this. Here's an example of a loader that would do what you want using env variable:

import {env} from 'node:process';
export async function resolve(spec, context, next) {
  const result = await next(spec, context);
  if (!context.parentURL) {
    if ('ENTRY_POINT_SEARCH' in env)
      result.url += `?${env.ENTRY_POINT_SEARCH}`;
    if ('ENTRY_POINT_HASH' in env)
      result.url += `#${env.ENTRY_POINT_HASH}`;
  }
  return result
}

[pinko-fowle]

It'd be great to have a feature like this. Ideally users shouldn't have to meddle with hooks to get the full flexibility of ESM.

There's similar questions of what Node can do on it's own (batteries-included) versus what a loader api might be able to do (do it yourself) in #34049. I keep hoping Node will just make ESM stuff directly supported.

[LiviaMedeiros]

Adapted the Loader Hooks API idea to an executable script that allows to $ launchByURL file.mjs?qwe=rty#uio directly: https://gist.github.com/LiviaMedeiros/76a553a86db90878121e58be65834eb3

Opened draft PR with an option to load ES module by URL with user-provided search and hash as $ node --module file.mjs?qwe=rty#uio: #49295

[GeoffreyBooth]

@nodejs/loaders @nodejs/modules

[GeoffreyBooth]

I don’t know why this is here, but the MDN documentation for import.meta discusses this:

The ES module implementation in Node.js supports resolving module specifiers containing query parameters (or the hash), as in the latter example. However, you cannot use queries or hashes when the module is specified through the CLI command (like node index.mjs?someURLInfo=5), because the CLI entrypoint uses a more CommonJS-like resolution mode, treating the path as a file path rather than a URL. To pass parameters to the entrypoint module, use CLI arguments and read them through process.argv instead (like node index.mjs --someURLInfo=5).

[LiviaMedeiros]

I don't see anything wrong with this note on MDN page: it correctly describes this limitation and suggests workaround for those who want to implement something similar in Node.js-specific way.
import.meta page is correct place to have it, because import.meta.url is the mechanism to retrieve these parameters.

If this issue gets fixed, the MDN page should be updated accordingly.

[github-actions]

There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.

For more information on how the project manages feature requests, please consult the feature request management document.

[pinko-fowle]

I'd love to see this.

Someone ought to bring this up with WinterCG. They're more server-focused than script-focused, but perhaps they'll bite?