Package versions aren't numbers and can't be treated as numbers. Node 10.7.0 is NOT the number 10.7, and node 10.18.0 is not the number 10.18. 10.7 is GREATER than 10.18, so this check fails:
This bit of code is attempting to work around an npm feature, enginesStrict. If a user wants to install a package that isn't compatible with their version of node, you shouldn't try to stop them.
Just because your library doesn't work in some old version of node does not mean that it won't work for the specific use case of the user installing it.
Example: I just need the TypeScript types from ipfs to be available. The code itself is never run. Please consider removing this check.
hildjj
commented
3 years ago
Package versions aren't numbers and can't be treated as numbers. Node 10.7.0 is NOT the number
10.7, and node10.18.0is not the number10.18.10.7is GREATER than10.18, so this check fails:https://github.com/hildjj/node-cbor/blob/2613cbc6883abc586f4da823f152a4d8f87d4a02/packages/cbor/.checkVersion.js#L7
That's not really the problem though.
This bit of code is attempting to work around an npm feature,
enginesStrict. If a user wants to install a package that isn't compatible with their version of node, you shouldn't try to stop them.Just because your library doesn't work in some old version of node does not mean that it won't work for the specific use case of the user installing it.
Example: I just need the TypeScript types from
ipfsto be available. The code itself is never run. Please consider removing this check.