Component/duo support, try catch?

[evansolomon]

Can you explain the idea behind the try/catch for a module that isn't part of the package in 3eacf6a? I get that the result is that parent apps may supply their own copy of node-extend by depending on it themselves, but I can't tell why they'd want to do that. I also don't know what "component/duo support" means, and it's hard to work out what's going on just from the diff.

My use case is that I have this module in my dependency tree (via mdast) in a React Native app, and the React Native packager doesn't really love modules that cannot be resolved, so I'm trying to figure out the best way to handle this. It looks like the node-extend module is quite old and the github repo doesn't even exist anymore, so I don't particularly want to add it to my app.

Thanks.

[wooorm]

Read more about Component and Duo. Read more about installation methods for mdast in its documentation.

This work-around is needed because the extend npm module is called node-extend on GitHub (the project called node-extend on npm is never used). GitHub is used by non-npm package managers.

I have no experience with “React Native packager”. It doesn’t yet seem to support the browser field, but they seem to be working on it.

I’m closing this because I think supporting the browser field in react-native/packager is the cleanest fix for this.

An alternative is the blacklistRE found in packager

[evansolomon]

Thanks for the response. Unfortunately I don't think the blacklist option is accessible from the packager CLI. For now I fixed the issue by just adding unified v2.1.0 to the root project's dependencies.