Incompatible with npm link or yarn link

[acao]

It seems this project is incompatible with yarn link and npm link. I'm a maintainer for graphiql, part of the GraphQL working group, and we have ~9 linked repositories that we have to add an empty and temporary "browserify-shim": {}, entry to in order to build the application across these linkages. Any suggestions on how to make this an easier project for our contributors?

[bendrucker]

Per the discussion in #208, I don't see how we can get past this. The only way browserify-shim has available to look up the relevant configuration is by traversing upwards and looking for package.json. I don't see how we can relax that restriction without breaking a key piece of validation.

I would consider a PR letting the user opt in and skip configuration lookup for specific packages, effectively preventing browserify-shim from operating on them. That's a pretty sloppy workaround but I don't see any way we can reasonably support npm link out of the box.

[acao]

Hmm I can see how that's an issue. Just wanted to note that it's a fairly common development pattern, and symlinks are also used by monorepo tooling such as lerna. Seems that some tools such as eslint have figured this out, but I doubt it was easy

[bendrucker]

The specific issue here is that:

1. browserify-shim is configured via package.json (not uncommon)
2. browserify-shim can be configured by any package in the tree, via the nearest ancestor package.json (very uncommon)

Something like eslint gets past this because the configuration's presence in package.json is for convenience, and not for mimicking the require algorithm as b-shim does. You can't, for example, specify eslint configuration for a specific sub-package by placing it in the sub-package's package.json file.

[bendrucker]

Browserify passes the original file path to the transform so AFAIK we have no way to get the symlink's path, only the underlying realpath.