module: report unreadable package.json - #65223
Conversation
A package.json that exists but cannot be read was treated the same as one that is not there: the read failure returned no config and resolution continued as if the package had none. Fields such as "exports" and "type" silently disappear, so a specifier can resolve to a different file than the package declares, while an unparsable package.json already throws ERR_INVALID_PACKAGE_CONFIG. Keep treating ENOENT and ENOTDIR as "no package config here", and report any other read failure with the underlying error. Fixes: nodejs#65220 Signed-off-by: Paul Bouchon <mail@bitpshr.net>
b4271b7 to
e3bd440
Compare
|
It could be worth checking what error used to be thrown here before the resolver was refactored into C++, as I'm pretty sure this did used to throw an error, it just clearly didn't have coverage. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #65223 +/- ##
==========================================
+ Coverage 90.15% 90.32% +0.16%
==========================================
Files 744 760 +16
Lines 242517 248608 +6091
Branches 45688 46934 +1246
==========================================
+ Hits 218642 224553 +5911
- Misses 15358 15471 +113
- Partials 8517 8584 +67
🚀 New features to boost your workflow:
|
|
Checked the commit before the resolver moved to C++ (f13dbfd, parent 4ec085b). The JS So the silent fallback looks like it predates the C++ move rather than being a regression from it, which fits there never being coverage. Happy to be wrong if you remember an earlier version that threw, I only went back as far as the refactor. |
Fixes #65220. A
package.jsonthat exists but cannot be read was treated as absent, soexportsandtypesilently disappeared and a specifier could resolve to a different file than the package declares. An unparsablepackage.jsonalready throwsERR_INVALID_PACKAGE_CONFIG, so this makes the unreadable case consistent: ENOENT and ENOTDIR still mean "no package config here", anything else reports the underlying error.Two alternatives if you'd prefer them: warn and keep resolving, or restrict the new error to the direct package lookup and stay silent while walking up for the nearest parent config. That second one matters if anyone relies on resolution succeeding past an unreadable
package.jsonin an ancestor directory. Happy to change course on either.Fixes: #65220