Fix: throw if not ENOENT #6
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We had a tricky bug at work using pnpm as it seemed to not read publicHoistPattern on some users' machines.
We worked out that it wasn't using or finding the .npmrc file. After lots of debugging we worked out that it should be loading the file but the settings were still empty/default.
I logged out the error that is swallowed on this line and I found:
I can understand the ENOENT errors being ignored since in many cases you're loading files that may not have been created, but in this case we were failing to interpolate an env variable and had no idea that was the issue. Since this was so painful to track down, I wanted to make a PR to try to improve the situation for anyone else.
Maybe there's a reason why these errors are always swallowed even if they're not ENOENT, but I can't imagine why. Still, I imagine this is a breaking change so I'm happy to discuss it. But the fact that it's swallowed at the npm-conf level means there's really nothing to PR against in the main repo.