React-native: invalid require() should throw at runtime to be try-catch-able like in Node/Browserify

[gre]

Product Pain: https://productpains.com/post/react-native/packager-invalid-require-should-throw-at-runtime-like-in-nodebrowserify-for-lib-consistency

invalid require() should only throw an exception at runtime,
packager should not produce this error:

uncaught error Error: UnableToResolveError: Unable to resolve module foo from ...: Invalid directory ...

This breaks some NPM library to work, for instance: https://github.com/davidbau/seedrandom/issues/31

[facebook-github-bot]

Hey gre, thanks for reporting this issue!

React Native, as you've probably heard, is getting really popular and truth is we're getting a bit overwhelmed by the activity surrounding it. There are just too many issues for us to manage properly.

• If you don't know how to do something or something is not working as you expect but not sure it's a bug, please ask on StackOverflow with the tag react-native or for more real time interactions, ask on Discord in the #react-native channel.
• If this is a feature request or a bug that you would like to be fixed, please report it on Product Pains. It has a ranking feature that lets us focus on the most important issues the community is experiencing.
• We welcome clear issues and PRs that are ready for in-depth discussion. Please provide screenshots where appropriate and always mention the version of React Native you're using. Thank you for your contributions!

[satya164]

Not throwing errors at compile time will lead to more problems. Developers might not realize a problem without testing the whole app. A better approach might be the following, like in node,

let myLib;

try {
    myLib = require('./some-module');
} catch (err) {
    myLib = require('./similar-module');
}

There is something similar for browserify - https://www.npmjs.com/package/browserify-optional

[Kureev]

What's the next actionable step for this issue?

[satya164]

cc @martinbigio , of course :)

[martinbigio]

As @satya164 mentioned, we want to fail hard at compile time if a dependency cannot be resolved. I think that if we want to support this use case we'll have to introduce a new transform similarly to what browserify does.

[jsierles]

@gre thanks for bringing up this issue. We're going to close the issue out to keep our issues as focused as possible on bugs. A PR would be a good next step, or adding this on Product Pains. Feel free to continue discussion on the closed issue!

[gre]

https://productpains.com/post/react-native/packager-invalid-require-should-throw-at-runtime-like-in-nodebrowserify-for-lib-consistency

[GantMan]

@martinbigio - I agree having a "require" should be fatal, due to the terminology, but wrapping it in a try/catch, pretty much means the user knew it was optional yes? This what node, does. Safe to say the user is well aware that the file may not be there.

If this continues to be an issue, and packager wants to be different from Node, then I say embrace being different and create a function like requiref, where a user is using a different function all-together that can be wrapped in a try/catch. Thoughts?

[jamesone]

Any update on this? It would be handy for local configs that don't need to be committed & built by services such as Buddybuild.