Browser field contains invalid route in npm about asap HOT 8 CLOSED

QuickStart should not try to follow browser fields that do not appear in program code.

from asap.

The thing is, it cannot know if the browser key does not appear in the program code, short of making browser keys absolute paths only (which, by the way goes against the proposed spec).

Say you route "a": "b", and you require("c") I need to first resolve "c" (say it resolves to "SOME_PATH/c.js") and then I need to resolve "a" too, to see if it resolves to "SOME_PATH/c.js" also, which it totally could, since there could be another browser key rule down the require line to make that happen.

from asap.

Whatever browserify does, you should do.

from asap.

Even if the approach is not "correct" though?

Another easier example to show the logic around this:

in package.json

"browser": {
  "./folder": "./folder-browser.js"
}

your package ./lib/file

`require("../folder")`

The "correct" approach is to resolve "../folder" first (which, say, resolves to "./folder/file.js") then look at browser, and resolve "./folder" to see if it resolves to "./folder/file.js" and if a match is found, route it to "./folder-browser.js".

The Browserify approach is to simply not allow the key-part of the browser field to be resolveable, therefore in Browserify, this needs to be the package.json:

"browser": {
  "./folder/file.js": "./folder-browser.js"
}

from asap.

Compatible is correct. Incompatible is incorrect.

from asap.

I don't necessarily disagree about compatibility, but we digress. The route is still invalid, and having an invalid route in the project just because Browserify is relaxed about routes is a bit meh. The real issue is not how Browserify calculates routes, the real issue is that Browserify does not care if a route does not exist. I was trying to explain why all routes should be resolvable from a logical point of view.

from asap.

The route is resolvable in development, which is one scenario in which browserify is used. It is not resolvable when used as a dependency, which is another scenario in which browserify is used. The browser field spec chose not to create separate "browserDev" and "browser" fields, but instead to just be relaxed about how it works.

from asap.

Adding tests back to the deployed package is not an option. I am sympathetic to the issue, but it is worth pushing back on incompatible tooling in this case.

from asap.