Compiling mongodb 7.5.0 from real source succeeds (162 modules, 3m12s), but the driver crashes during client.connect() — inside its own handshake code, before any CRUD runs.
Error [MODULE_NOT_FOUND]: Cannot find module '../../../package.json'
Found by the package-compilability probe on 91a566c8af (v0.5.1605), Linux x64.
The site
node_modules/mongodb/lib/cmap/handshake/client_metadata.js:12:
const NODE_DRIVER_VERSION = require('../../../package.json').version;
A three-levels-up relative require() of a JSON file, resolving to the package's own package.json. It fires while building the wire-protocol handshake metadata, so it is on the connect path and unavoidable — every mongodb user hits it immediately.
Node resolves this fine; Perry does not, in this graph.
What I could not reproduce, which is the interesting part
Two isolation attempts both failed to reproduce:
- A synthetic package literally named
mongodb with the same three-levels-deep relative-require-of-JSON shape.
- A copy of the real 240-line
client_metadata.js dropped into that synthetic package.
Both resolved correctly under Perry. The failure only appears inside mongodb's actual 162-module graph. So the shape alone is not sufficient — something about the surrounding graph (module ordering, a cached resolution, the depth or identity of the requiring module) participates.
That is worth stating prominently because it means the obvious fix — "make three-levels-up relative JSON requires work" — may already be true, and the real defect is in how the path is resolved for this module in this graph. Anyone starting from the error text alone will write a test that passes.
Reproduction
mkdir mongo-probe && cd mongo-probe
npm install mongodb@7.5.0
# package.json: { "perry": { "compilePackages": ["mongodb"] } }
# fixture.ts: connect to a local mongod, insert and read one document
perry compile fixture.ts -o fixture && ./fixture
A local mongod is needed; the crash happens at connect(), before any collection work.
Not determined
Whether the resolution failure is about the relative path, the .json extension, the requiring module's own resolved identity, or a cache interaction — only that it needs the real graph to manifest.
Compiling
mongodb7.5.0 from real source succeeds (162 modules, 3m12s), but the driver crashes duringclient.connect()— inside its own handshake code, before any CRUD runs.Found by the package-compilability probe on
91a566c8af(v0.5.1605), Linux x64.The site
node_modules/mongodb/lib/cmap/handshake/client_metadata.js:12:A three-levels-up relative
require()of a JSON file, resolving to the package's ownpackage.json. It fires while building the wire-protocol handshake metadata, so it is on the connect path and unavoidable — every mongodb user hits it immediately.Node resolves this fine; Perry does not, in this graph.
What I could not reproduce, which is the interesting part
Two isolation attempts both failed to reproduce:
mongodbwith the same three-levels-deep relative-require-of-JSON shape.client_metadata.jsdropped into that synthetic package.Both resolved correctly under Perry. The failure only appears inside mongodb's actual 162-module graph. So the shape alone is not sufficient — something about the surrounding graph (module ordering, a cached resolution, the depth or identity of the requiring module) participates.
That is worth stating prominently because it means the obvious fix — "make three-levels-up relative JSON requires work" — may already be true, and the real defect is in how the path is resolved for this module in this graph. Anyone starting from the error text alone will write a test that passes.
Reproduction
A local
mongodis needed; the crash happens atconnect(), before any collection work.Not determined
Whether the resolution failure is about the relative path, the
.jsonextension, the requiring module's own resolved identity, or a cache interaction — only that it needs the real graph to manifest.