Update dependency true-myth to v8 #407
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![renovate[bot]](https://avatars.githubusercontent.com/in/2740?s=60&v=4){kind=small}
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
^6.2.0->^8.0.0Release Notes
true-myth/true-myth (true-myth)
v8.0.1Compare Source
🐛 Bug Fix
Committers: 1
v8.0.0Compare Source
This is a pretty small “breaking” release: it makes a change so True Myth is more type safe than it was before, specifically when constructing known-
Okor known-Errtypes withResult.okandResult.err. In earlier versions, if you wroteResult.ok(123), the type would beResult<number, unknown>. New contributor @auvred pointed out that in that case, we know there is never an error type, though, so we can use thenevertype. This is breaking in that you may have to explicitly annotate some types where you did not before, because of the assignability rules forunknownandnever(cf. this playground).Net, very little of your code should have to change, but where it does, it will be safer than it was before! Thanks to @auvred for the improvement!
💥 Breaking Change
Result.okand ok type inResult.errtoneverby default (@auvred)🚀 Enhancement
Result.okand ok type inResult.errtoneverby default (@auvred)📝 Documentation
Committers: 2
v7.4.0Compare Source
🚀 Enhancement
📝 Documentation
toString()(@chriskrycho)Committers: 2
v7.3.0Compare Source
🚀 Enhancement
nullandundefinedas arguments toMaybe.just(@chriskrycho)Committers: 1
v7.2.1Compare Source
🐛 Bug Fix
nullandundefinedin function return types (@chriskrycho)🏠 Internal
Committers: 1
v7.2.0Compare Source
🚀 Enhancement
find()(@screendriver)🏠 Internal
AnyArraytype in maybe.ts (@chriskrycho)Committers: 2
v7.1.0Compare Source
🚀 Enhancement
📝 Documentation
transposeArray(@chriskrycho)🏠 Internal
Committers: 2
v7.0.1Compare Source
🐛 Bug Fix
exportsmap (@chriskrycho)🏠 Internal
Committers: 1
v7.0.0Compare Source
💥 Breaking Change
🚀 Enhancement
Ok.cast()andErr.cast()methods (@chriskrycho)📝 Documentation
🏠 Internal
Committers: 3
Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about these updates again.
This PR was generated by Mend Renovate. View the repository job log.