browser entry point

[Fil]

Re: #1156 (comment).

Instead of taking at face value what pathResolution returns, we find package.json then see if the "browser" condition  entry point is present and update pathResolution as a consequence. The spec indicates that there are two possibilities to cover:

• a string (found in e.g. "[email protected]"),
• a replacement map (found in e.g. "[email protected]").

My tests use two modules that are already here by "chance", and will break if any of these modules gets updated (for example supports-color@9 does not use the browser field anymore), but we can fix that when it happens. (Alternatively, we could add these precise versions in devDependencies just for these tests?)

I checked what @rollup/plugin-node-resolve plugin does: it looks at the entry with the condition key in resolvePackageTarget. The chain of calls: < resolvePackageImportsExports < resolvePackageImports < resolveImportSpecifiers < resolveImportSpecifiers

[mbostock]

This is using the browser entry point (or “main field”) which is different from the browser condition within the exports object, which is what I was referring to. The latter is the modern standard that is the top priority to support. I suppose we should also support the browser field too as a fallback (and maybe jsdelivr and unpkg fields, like d3-require does?). It sure is complicated! At least there are modern standards for this, but it’ll be a bit of a mess to try to make everything work.

[mbostock]

Also I wanted to see if there is a way to use Rollup’s node-resolve plugin to figure some of this stuff out for us. I think it might be possible, but I’m not sure. Anyway I appreciate your help cracking this nut!

[Fil]

yup, I also feel this is something that should be left to rollup.

[mbostock]

Superseded by 50a3e7d.

[mbostock]

(I’ll work on porting the tests now.)

[mbostock]

Hmm, I don’t have a good way of porting the tests because we no longer return the resolved path to the entry point — we just pass the entry name to rollup and let it figure it out. So the default entry name is . which we rename to index.js (because we need the .js extension, and I’m assuming no one would need both . and index.js to refer to different things). We’d have to test the transpiled contents, I think. Maybe we need to hand-craft some packages to test.