Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Resolve Modules #83

Open
pemrouz opened this issue Aug 7, 2016 · 8 comments
Open

Feature Request: Resolve Modules #83

pemrouz opened this issue Aug 7, 2016 · 8 comments

Comments

@pemrouz
Copy link

pemrouz commented Aug 7, 2016

In addition to paths, it would be nice to resolve module names:

"browser": "foo"

Before npm used to dedupe packages, it was possible to reliably do something like:

"browser": "./node_modules/foo/index.js"

Happy to open a PR - I just wanted to check if this is desirable or not first.

@defunctzombie
Copy link
Collaborator

hm, not sure what I think of this. What is the thinking here? You would have the browser specific code of the module in a separate module and want to reference it?

@pemrouz
Copy link
Author

pemrouz commented Aug 7, 2016

I think in general most people would expect this to resolve similar to how require resolves.

The specific use case is that I have a bunch of modules that I want to resolve to the identity function (or other times, noop) in the browser, such that when you require this universal module the server-side modules are skipped over in the browser. This is similar to browser: false, but that's restricted to converting to an empty object, which is not always the desired behaviour (i.e. I don't want to throw lots of "object is not a function" errors, or have to add an empty function to each module (ending with multiple in the bundle), or add lots of if statements to work around only being able to dedupe to an empty object).

@pemrouz
Copy link
Author

pemrouz commented Sep 3, 2016

@defunctzombie - any more thoughts on this?

@defunctzombie
Copy link
Collaborator

I think this is a good idea. We first need to add it here (https://github.com/defunctzombie/package-browser-field-spec) to document the desired behavior (and probably start a changelog on that page to notify people of spec updates).

Separately, seeing a PR on this here would help folks in testing the feature.

@substack @sokra @Rich-Harris since you all I believe are involved with the more popular package managers. Do you support the browser field spec (I believe browserify and webpack do but could be mistaken)

@sokra
Copy link

sokra commented Sep 5, 2016

I'm on board 👍

@pemrouz
Copy link
Author

pemrouz commented Sep 10, 2016

Thanks for the direction @defunctzombie 👍

Opened PRs #84 and defunctzombie/package-browser-field-spec#6

@pemrouz
Copy link
Author

pemrouz commented Dec 6, 2016

bumping.. is there anything else required before we can land this?

@sokra, @Rich-Harris: do you make use of node-browser-resolve too or do we need to patch something else?

@dy
Copy link

dy commented Nov 28, 2018

Related issue browserify/browserify#1539.
Any plans to merge #84 @defunctzombie @sokra?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants