You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Instead of opting to replace when compiling to the distribution
files, this refactoring uses the `package.json`s `browser`
field. This ensures other tools adhering to that `browser`
field work.
Related to GH-1.
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
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.
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.
The text was updated successfully, but these errors were encountered: