Change type names to be more consistent #6503
Conversation
The `Plugin` type should be used as a return type of the `createPlugin()` function.
🦋 Changeset detectedLatest commit: 8475bda The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
jeddy3
changed the title
| @@ -0,0 +1,5 @@ | |||
| --- | |||
| "stylelint": major | |||
There was a problem hiding this comment.
I doubt if only type definition change should be considered as a breaking. Such a change does not break anything about runtime behavior but may raise a type-check error.
Do you have any (semver) guidelines about such a change?
EDIT: If considered as breaking, it will not be possible to refactor the type definitions easily.
There was a problem hiding this comment.
Do you have any (semver) guidelines about such a change?
We don't. Is there a defacto approach for packages that publish types that we could adopt?
If not, let's just switch back to refactor like you originally had it.
There was a problem hiding this comment.
Is there a defacto approach for packages that publish types that we could adopt?
I'm not sure if it exists or not... 🤷🏼
There was a problem hiding this comment.
When I googled, the following website is found:
Semantic Versioning for TypeScript Types - https://www.semver-ts.org/
EDIT: I guess this guide is not defacto, maybe.
There was a problem hiding this comment.
When I read semver-ts.org, I feel a bit too strict, honestly.
However, aside from the future, because it's obvious that there's a possibility of breaking anything, I have no objections to considering this PR as breaking. 👍🏼
Follow-up for #6481
The
Plugintype should be used as a return type of thecreatePlugin()function.Type-checking failures may occur if people use the types changed in this PR, but I believe they accept the failures because of the major update (v15).