Is "browser" field supported in node_modules dependencies?

[acailly]

❔ Question

Does Parcel handle browser fields defined in node_modules the same way browserify and webpack do?

🔦 Context

I try to use ipfs as a dependency and I found that browser field seem to be ignored by Parcel becaus it doesn't load the browser version of files and doesn't ignore files marked as false.
(for example: https://github.com/ipfs/js-ipfs/blob/master/package.json#L11)

I found that another user have a very similar issue (#200 (comment)), which makes me thinks that Parcel does not handle this field the same way browserify and webpack do

And I found that another user had an issue with a missconfigured browser field in a node_modules dependency (#1631) which makes me think that Parcel does handle this field the same way browserify and webpack do

... and I've not found any documentation regarding this field so I'm asking the question

🌍 Your Environment

Software	Version(s)
Parcel	1.9.7
Node	8.10.0
npm/Yarn	yarn 1.9.4
Operating System	Windows 10 64bits

[acailly]

Continuing investigation, I made a simple example here and it seems that browser field is handled: https://gist.github.com/acailly/986047b786bf2dc247ea47bd2b0a1115

Maybe that means that the problem is related to IPFS lib...

[DeMoorJasper]

Feel free to contribute docs about the browser field here: https://github.com/parcel-bundler/website

We appreciate any contribution to the docs.

the browser field should be fully supported in parcel

[acailly]

I would like to but I still don't understand why it's not working.

I forked my previous example to use ipfs instead of on-load and this doesn't work and I don't know why (see
https://gist.github.com/acailly/648d1a6e28c8939bbdf84499851c626d to reproduce)

I checked with webpack and browserify with the same example and it worked.

I have no clue why it's happening 😕

[DeMoorJasper]

Works perfectly for me, your example is missing a polyfill though.

Add this to the first line of index.js

require('babel-polyfill');

Parcel should automagically install it

[acailly]

I just tried with require('babel-polyfill');, tried with an upgraded yarn, tried with npm, always the same error 😞

[DeMoorJasper]

What is the error?

[acailly]

Sorry, I thought I had posted it already

×  C:\_Projets\temp\test-parcel-browser\node_modules\fs-ext\fs-ext.js:22:22: Cannot resolve dependency './build/Release/fs-ext' at 'C:\_Projets\temp\test-parcel-browser\node_modules\fs-ext\build\Release\fs-ext'
  20 | "use strict";
  21 |
> 22 | var binding = require('./build/Release/fs-ext');
     |                       ^
  23 | var fs = require('fs');
  24 | var constants = require('constants');
  25 |

The code causing the error should not be executed in browser, it is the node version of the lib

[DeMoorJasper]

I don't know, seems to work for me, might be something with windows as we don't test anything on it anymore (as all/most contributors use mac)

[raoulmillais]

There is definitely a divergence of behaviour handling the browser field of dependent packages on windows vs unix systems. A more minimal test case to reproduce the behaviour is:

1. Create 2 packages
   • package A has an index.js file that requires a local sibling package, package B
   • package B requires a file ./src/dep.js and has a browser field with ./src/dep.js": "./src/shim.js"
   • shim.js console.logs 'i am the shim'
   • dep.js console.logs 'I am the default'
2. parcel build .\index.js inside package A
3. node .\dist\index.js

This outputs 'i am the default' .

The bug only appears when the browser field is a relative path with more than 1 component.

[danmarshall]

I'm also seeing this bug - I'm also on Windows. Here is a repo demonstrating this bug.

[danmarshall]

Happens only in subfolders, which add that extra backslash. PR sent 👍