proposal-pkg-exports icon indicating copy to clipboard operation
proposal-pkg-exports copied to clipboard

How would loader hooks/extensions/plugins leverage this?

Open jkrems opened this issue 5 years ago • 5 comments

If I'm writing a custom resolution algorithm, will there be a way to still leverage this behavior? Let's say I resolve to a package mapped to non-file: URLs. How do I still allow that package to specify exports?

jkrems avatar Nov 07 '18 23:11 jkrems

also of note,

if using import "foo/bar"; from main.mjs what is passed to loaders?

{specifier: "foo/bar", referrer: refTo("main.mjs")} would require the loader to lookup foo/package.json to find out what foo/bar is pointing to if it wants to know the actual file location. However, foo/package.json could have been overridden it seems?

bmeck avatar Nov 08 '18 00:11 bmeck

  1. We should track that /package.json is blacklisted at the very least. I don't think I would want to open that particular can of worms.
  2. Thanks for those additional questions! Also interesting in the context of arbitrary resource loading - who and when and how does load package.json and provides this data.

jkrems avatar Nov 08 '18 15:11 jkrems

Currently import statements only import .mjs files, so importing package.json isn’t possible; but we might as well blacklist it and package-lock.json I suppose, or maybe wait until someone proposes allowing import statements of JSON to address it then.

So I guess this theoretical loader does its work before Node tries to resolve these references, so Node doesn’t know the file paths to pass to the loader. But Node could perhaps load package.json and pass its contents to any loaders, to avoid double (or more) lookups of package.json from the file system.

GeoffreyBooth avatar Nov 09 '18 05:11 GeoffreyBooth

@GeoffreyBooth The issue would be redirecting the package.json. E.g.:

{
  "exports": {
    "/package.json": "./run-random-code-to-generate-data.mjs"
  }
}

jkrems avatar Nov 09 '18 16:11 jkrems

Also, for additional context: The import-map proposal goes beyond ESM import but is introducing a context-sensitive import: URL scheme that may be used for resource loading in general. It stands to reason that the meta data would be loaded via the same resource system that would also provide the package contents. This is all very forward/future looking at this point.

jkrems avatar Nov 09 '18 16:11 jkrems