Closed michaelfig closed 7 months ago
I think this would only work for the endo repo, right? The top level package.json
and the yarn.lock
has no influence on the repos consuming endo packages.
I think this would only work for the endo repo, right? The top level
package.json
and theyarn.lock
has no influence on the repos consuming endo packages.
It's the @typescript-eslint
devDependencies pulling in ts-api-utils
, so if Node.js 16 is used to run yarn
in Endo (as it is in the breaking dapp integration tests), it fails without these changes.
But you're right; I've just now pinned the versions in eslint-plugin
, stream-node
and stream
, which also had references to @typescript-eslint
.
🐤, How does this fix work mechanically? I think this is narrowing the range of eligible versions (from the broader constraints mentioned in some transitive dependency)
That's exactly what it's doing. If the transitive dependencies change their accepted version range to reject 1.0.x
, this engine restriction will happen again. I'm just buying a little time until then.
Description
Temporarily fixate on
ts-api-utils@1.0.x
not to force downstream simultaneous mass migration from Node.js 16. Those users can take migration into their own hands, rather than being a breaking change.Security Considerations
Scaling Considerations
Documentation Considerations
Testing Considerations
Compatibility Considerations
Upgrade Considerations
*BREAKING*:
in the commit message with migration instructions for any breaking change.NEWS.md
for user-facing changes.