<isd>
I think pinning to 4.7 might be the best short term solution
<isd>
Apparently newer versions of the mongodb package provide their own type declarations. so this is unliikely to get fixed without moving to a new version of the driver...
<ocdtrekkie>
Of course
<isd>
Why does typescript not follow semver.
<ocdtrekkie>
Microsoft.
<isd>
But yes, require('node:child_process') works on my system's node, but not the one shipped with sandstorm (but the require('child_process') does).
<ocdtrekkie>
So like... do we need to pin multiple more things back to avoid breakage while we're retaining the old Mongo? I swear we must've hit some "ah, it's old enough now, breaking changes galore" with all these.
<isd>
doing grep -r node:child_process I find a number of spots where there seem to be version constraints asking for node >= 16
<isd>
whereas we still seem to be on 14
<isd>
one of those is babel
<isd>
so that's probably injecting the bogus imports
<ocdtrekkie>
That'd be a screw up on their end, then, right? Because they're making incompatible changes with Node 14 on a version they're claiming works with Node 14?
<isd>
Who is they?
<ocdtrekkie>
babel?
<ocdtrekkie>
I'm just seeing the "npm still scares me" comment on your recent doc and going "like this stuff".
<isd>
hah
<isd>
But I think babel is actually saying it needs node >=16. hard to tell; it's deep in some dependency of meteor.
<isd>
That's not just a regular package.json though. Blurgh.
<ocdtrekkie>
is-core-module appears to have a bunch of logic around whether modules should have node: or not based on the node version, I think? One of the top packages that depends on it... is "resolve" again.
<ocdtrekkie>
Ah. The resolve issue is apparently caused by an intentionally broken file in tests.
<ocdtrekkie>
And one can delete that during the build process with no real impact.
<isd>
So maybe we should just add deleting that to the build logic.
<ocdtrekkie>
That would let Kenton not have to revert resolve, but you're right in that I don't know if it'd fix much else. Looks like is-core-module saw one version update in August? And then one back in April.
<isd>
So it's unlikely that's the problem
<ocdtrekkie>
The reference to node:child_process in is-core-module was added 13 months ago.
<isd>
Hm, probably that's a red herring
<ocdtrekkie>
I suspect it is.
<isd>
I bet that's just the threshold above which it's supposed to use the node: prefix