consider supporting the "browser" field of package.json

[zevdg]

Do you want to request a feature or report a bug?

feature

What is the current behavior?
yarn totally ignores the browser field in package.json
spec: https://github.com/defunctzombie/package-browser-field-spec
current support: https://github.com/stereobooster/package.json#browser

If the current behavior is a bug, please provide the steps to reproduce.

N/A

What is the expected behavior?
Ideally, I could let yarn know that I am building a project specifically for the browser (with a new --browser flag or something like that). When this flag is used, yarn would make use of this field when resolving dependencies. Specifically, I'm interested in the ignore a module hint. The motivation for this request is coming from firebase/firebase-js-sdk#546 (comment).

Obviously, since yarn works on a package level, it could not possibly do anything about the file level hints in this field, but module ignores (and possibly the module replacements) seem very doable.

Please mention your node.js, yarn and operating system version.
node: v8.9.4
yarn: 1.5.1
os: linux 4.15.7

[rally25rs]

I don't think there is anything yarn can do with this.
It isn't an npm documented package.json field: https://docs.npmjs.com/files/package.json
and the places it seems to be used is by application like webpack that actually produce some output.

Could you resolve some of the --flat issues with resolutions? You could map the different versions to all point to the same one so that flat would work.

"ignore a module" seems to be the only use-case of the browser field that yarn could potentially do anything with. Modifying the existing resolutions feature to have an option to "ignore / don't install" a module could have some value, but I'm not sure how wide-spread it is for consumers to want to not install certain transitive dependencies.

[zevdg]

That is what I'm doing currently and it seems to be working for now, but that solution is very brittle because AFAICT, resolutions gets forced on all dependencies (including dev ones).

I'd love to be able to flatten everything, but that just isn't how the server side javascript world operates and unfortunately, dev dependencies like webpack heavily resist being flattened. Currently, webpack pulls in 21 libs that must be manually overridden and any one of those overrides could break functionality. Frankly, it's ok if my dev tools require multiple lib copies. It's really only the dependencies that I'm delivering to my users (aka prod dependencies) that should be flattened. I'm happy to let my dev dependencies use as many versions of libs as they want/need. I suspect many javascript developers are in the same boat, but yarn doesn't directly support this use case. Even if you can resolve safely, yarn install && yarn install --prod --flat does a lot of unnecessary work that could be avoided if this workflow were supported more directly.

AFAICT, putting something into resolutions imposes that on both my prod AND my dev dependencies. Which is fine until it brakes one of my dev dependencies. If there is a backwards incompatible change and webpack or something else actually does need both versions of the library, it looks like I'd be screwed. Is there a way to work around this that I'm not seeing?

IMO the default behavior of --flat and resolutions ought to only affect production dependencies and there should be a separate option to extend the behavior to dev dependencies (although I'm not sure why anyone would ever want to do that).

[zevdg]

Ah, I just found the related discussion in #3254
Even if this proposed --dev flag were added, it still wouldn't fix this problem.

The "resolutions" field still always gets applied. I'd also need something like --ignore-resolutions.
Then

yarn install --prod --flat
yarn install --dev --ignore-resolutions

would allow the resolutions field to solve this issue for me.

[zevdg]

Modifying the existing resolutions feature to have an option to "ignore / don't install" a module could have some value, but I'm not sure how wide-spread it is for consumers to want to not install certain transitive dependencies.

That feature has been requested in a more general way already #4611

[rally25rs]

yarn aside, I struggled with this a bit when Bower started leaning toward "we aren't going to support this any more" and I had to start moving toward npm or yarn instead. I wasn't sure how to have non-flattened dev deps and flattened web deps (and I never solved that).

If you are using webpack, then I think having multiple versions of a web dependency will actually work. It should be resolving packages like node.js would, so an import or require from different files could pull in different copies of a library.

Keep in mind that npm wasn't designed for web packages. IMO they shouldn't even be in the npm registry. Bower was good for managing those. It's unfortunate that they are deprecating it.

Since you found 2 other issues that are semi-related to this, do you want to keep this issue open or do you mind if we close it?

[zevdg]

This is fine to close. I just wanted to make you guys aware of this use case. Namely: isomorphic packages pulling in large conditional dependencies that are not necessary when the library is being used as a web package.

It's just frustrating that the humans know about this large dependency subtree that can/should be excluded from the package resolution process, but we have no way to convey this to the tooling. Having some way to mark these packages for exclusion (whether its via the browser field, or the resolution field, or something else) would ease some of the pain of using npm for this thing it wasn't initially designed for.

Fortunately, it looks like flattening is being discussed/addressed in a more comprehensive way over at package-community/discussions#2

[Pajn]

Improving the situation for frontend applications in general would be great. A lot of the discussion in package-community/discussions#2 generalizes to all frontend applications, even if they are not using polymer.

[JamieMason]

I don't think there is anything yarn can do with this.
It isn't an npm documented package.json field: https://docs.npmjs.com/files/package.json
and the places it seems to be used is by application like webpack that actually produce some output.
@rally25rs

I'm sure you were correct at the time of writing but just mentioning as I stumbled on this thread that browser is documented here: https://docs.npmjs.com/files/package.json#browser.

[Janaka-Steph]

UP! I want to import in a web project a module built with tsdx, that has a browser and a Node version. Yarn ignores the browser field of that module and by default I import the Node version.