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 nodejs/node#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):

pkg
   /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.