-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support TypeScript 3.7 Assertions #47
Comments
Hi @cartolari This is a great idea. I will add this. The only worry I have is backwards compatibility in the type definitions ( Any opinions from users of |
We're just starting to use the library to validate what we pull out of the database or redis matches what we expect to get. Right now we've been dropping it into our lowest level wrappers like
It wouldn't be too hard to switch over to to the newer style. We'd probably prefer it because we try to stay no more than 1 version off of the newest minor typescript release. |
Hi @joshAg Thanks for sharing your situation. It helps me gauge the need for assert signatures. One thing that still concerns me is that people who are sticking with older versions of TS will probably run into compiler errors with the new syntax. Maybe one solution is to keep two versions of typescript-is in parallel, one with assert syntax and one without? At some point in the future however I'd like to converge to one version, once there has been enough time to migrate for everyone. I'm pretty new to managing open source projects so I'd like some opinions on how to move forward :) |
I don't have a lot of experience for open source as well, but at least for commercial/internal projects, for a breaking change, we've done it in two steps of the major version. The first step will deprecate the older usage but keep functionality at least at par with the previous version. It's usually not worth the hassle to add functionality/features to match the new usage, nor is it worth it to remove functionality/features that are added as a result of improving something shared between new and old. It is worth it to add functionality that makes it easier to switch from the old style tot he new style. Both old and new should get security updates, too.The second will actually remove the old usage from the code base. You can move as quickly or as slowly as you want between those two steps (even releasing both versions the same day), but the important bit is having at least one version where both are supported so that downstream projects can use that version to migrate the code from the old to the new version, and verify that everything still works correctly. If there are missing features in the new functionality that prevent a full migration from old to new style, you'll want to add them to the intermediate major version if at all possible and not just add them to the latest version, because the missing feature prevents seamless upgrades (which means they'll be opening issue for a code workaround until they get to the actual feature they need by upgrading). The easier it is for users to transition from old to new, the less time you'll spend convincing people to migrate or helping them figure out how to migrate. It looks like there already exist ways to specify which version of typescript are supported too: microsoft/TypeScript#32166 |
Thanks for linking this issue microsoft/TypeScript#32166 |
TypeScript 3.7 introduces the assert keyword microsoft/TypeScript#32695, it allows code to be written this way:
instead of this:
It'd be good if the library provided support for it, maybe using a new function if backwards compatibility is required.
The text was updated successfully, but these errors were encountered: