Modules: import-maps a proposal for bare imports in browsers

[MylesBorins]

Domenic opened a new repo with a proposal for Package Name maps, a mechanism for allowing for bare imports in the browser. This potentially allows for a consistent resolution algorithm between platforms.

Thoughts?

https://github.com/domenic/package-name-maps

[weswigham]

TypeScript already has support for a similar config, as did/does requireJS, webpack, and the babel module resolver plugin, though it's not particularly easy to use compared to the convention-based default node resolution. 😛

So while it works (and has been in use to map node-style paths to browser-capable ones for somewhere between a half-decade and a decade), and would definitely improve things in the browser, I'm not sure it'd get browsers all the way to where people are really _satisfied_? It's definitely better than needing to edit the imports in every file, anyway; though I think it may need more work on how lodash/pick maps to lodash/pick.js if only lodash has a specified mapping (since I don't see any mention of an implied extension).

I imagine it's definitely worth supporting, for the sake of mirroring what the browser of capable of, but it's not really the kind of experience a node dev has come to expect as the default.

[devsnek]

not sure why we can't just wait for whatwg to finish the proper hookable loader /cc @domenic

[ljharb]

I wonder if maybe there was a way to use this map to specify a way to handle all bare imports without having to specify each one?

[domenic]

@devsnek https://github.com/domenic/package-name-maps#a-programmable-resolution-hook

@ljharb https://github.com/domenic/package-name-maps#a-convention-based-flat-mapping

[justinfagnani]

@weswigham

though I think it may need more work on how lodash/pick maps to lodash/pick.js if only lodash has a specified mapping (since I don't see any mention of an implied extension).

I think it's an open question whether the format will support that. At the limit it could bloat the package name map with an entry for every file, or involve a lot more complexity in constructing paths from various settings. Currently, I rather like the idea that resolution is just mapping the package name to a path, and supporting a main file, but everything after the package name is a path within the package.

[MylesBorins]

to expand on @justinfagnani's point... I think that the package-name-maps supports the majority of the module specifier loader algorithm in node, except for two primary cases

• file extensions are mandatory
• directories cannot be imported

[benjamingr]

I think we should invite @domenic to the team if possible or at least to the next meeting to discuss.

[justinfagnani]

I was going to offer to present the proposal at the next meeting.

[jasnell]

@MylesBorins @domenic ... where would you prefer feedback on this design to be directed? Here or in the package-name-maps repo?

[justinfagnani]

@jasnell in the package-name-maps repo

[MylesBorins]

@bmeck has brought up concerns about this proposal over in https://github.com/nodejs/node/pull/21729

Putting this back on the agenda so we can discuss. We can also do so in the issue

[demurgos]

@bmeck
In todays meeting you mentioned that package name maps can help resolving extensionless specifiers and that you have some examples.
I couldn't find it mentioned on the proposal's README. Could you share these examples?

[bmeck]

@demurgos you can do creative things like (note that we are working with preliminary spec and things might change):

   /lib
      index.js

{
  "path_prefix": "/node_modules",
  "packages": {
    "pkg": {"main": "lib/index.js"},
    "pkg/lib": {"main": "index.js"},
    "pkg/lib/index": {"path":"pkg/lib", "main": "index.js"}
  }
}

[MylesBorins]

Removing from agenda for now, can be re-added

[MylesBorins]

Closing this as there has been no movement in a while, please feel free to re-open or ask me to do so if you are unable to.