9.0.0 #190
9.0.0 #190
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Co-authored-by: Elliot Winkler <[email protected]>
| - Bump dependency `semver` from `^5.7.1` to `^7.6.0` ([#181](https://github.com/MetaMask/utils/pull/181)). | ||
|
|
||
| ### Fixed | ||
| - **BREAKING:** Replace dependency `superstruct` `^1.0.3` with ESM-compatible `@metamask/superstruct` `^3.0.0` ([#185](https://github.com/MetaMask/utils/pull/185)). |
There was a problem hiding this comment.
Maybe we should note why this is breaking? Or is this breaking? I think we still use the same functionality.
There was a problem hiding this comment.
Here's the compare link for the package.json diff between these versions. The exports field and the dual type declaration files are added after we switch to @metamask/superstruct.
There was a problem hiding this comment.
Or wait would this dependency replacement not be a breaking change even if the dependency contains breaking changes?
There was a problem hiding this comment.
My intuition is that since superstruct@^1.0.3 broke downstream packages of @metamask/utils by preventing them from being imported into TypeScript projects (e.g. core/*) that use the NodeNext setting for moduleResolution, the fixes introduced by @metamask/superstruct should count as breaking changes.
By that logic, it seems the type declaration files fix might also be a breaking change, since it fixes an issue that was breaking downstream packages, not just directly but also via nested dependencies.
Both of these might count as cases where a fix may need to be announced as a breaking change.
There was a problem hiding this comment.
Hmm. superstruct is definitely unusable in a project that uses moduleResolution of nodenext, and that means that @metamask/utils is unusable too. So, upgrading this dependency makes @metamask/utils usable again (i.e. it's a fix). So, are there cases where this upgrade would break other kinds of TypeScript projects that currently use @metamask/utils? I don't believe the changes to the exports propagate to @metamask/utils, so people would be able to import it the same way. But, for instance, are there any specific TS compiler settings that a project would no longer be able to use after this upgrade?
There was a problem hiding this comment.
All good points! I'm finding that reverting the TypeScript version and module, moduleResolution settings on the core v5.0 upgrade PR does cause breakage, but so far I'm mostly seeing errors related to the multiformats dynamic import. I'll try out other compiler options combinations to see if any errors related to @metamask/utils pop up.
There was a problem hiding this comment.
It doesn't look like the switch to @metamask/superstruct causes any new restrictions for downstream packages. Since there are no breaking changes left, I'll close this PR and create a new minor release.
|
Closing to convert to minor release. |
This is the release candidate for version 9.0.0.