> No. It's a language compiler. You can upgrade it safely without changing a single line in your codebase. If there is a breaking change (sometimes, regarding the strictness) there's also a configuration option that lets you keep the previous behavior.
I am currently stuck on a very difficult issue because of a TypeScript upgrade. The upgrade caused a type mismatch with a dependency that wasn't previously an issue, and due to the lack of documentation on that dependency I am currently trawling through source code.
> And so you're going to lose any and all typing as your solution? I don't understand. Undocumented but typed >>> undocumented and untyped.
No documentation of types means going into source code to see what is there. Sometimes there could be multiple types that could be used for something, and it's not clear which should be used. Most libraries have clear docs to show me how to use a function, I'll take that any day over the uncertainty of which type may be correct in many places in my codebase.
> Doesn't matter. Use SWC or esbuild for sub-100ms compilation times. Your CI is a long running job due to tests and lint anyways. Nobody is writing pure uncompiled JS these days - you can't use NPM libraries that way, so there's always some (Web)pack step. I haven't seen a single developer who liked having to care about browser versions and wants to go back to that - but if you add a compilation step you get that for free and can write the latest and greatest.
Not arguing for no transpilation though browser compatibility isn't much of an issue these days unless you are using some super new features of the language (the reason is more about bundling the code together and jsx as far as I understand). I am arguing that each transpilation step adds yet more config that needs to be built, understood and maintained. TypeScript is probably the worst offender, almost as much work as maintaining another webpack config in your projects.
Did you upgrade Typescript (and if so, why), or did you upgrade some project dependencies, or type definitions?
> No documentation of types means going into source code to see what is there. Sometimes there could be multiple types that could be used for something, and it's not clear which should be used.
I haven't had this experience, and I'm not super experienced with Typescript. Are you using VS Code? It typically makes it trivial to find the definitions of things I'm interacting with in the editor.
> Did you upgrade Typescript (and if so, why), or did you upgrade some project dependencies, or type definitions?
I need to upgrade it because I upgraded a dependency that needed a newer version of TypeScript to compile! And I needed that dependency to be upgraded to use a newer version of NodeJS.
It seems that the newer version of TS was more strict, and now I can't find a type from ProtobufJS that fits the code. I can update here when I understand more about this particular case, but presently my best bet is to loose some typing and autocompleting by using some unknown types :(
What an odd question! Even ignoring new features and better type inference that comes with new versions — once you add typescript to your project, it becomes one of its dependencies. Don't you regularly update your dependencies, just as a good practice, not to let your codebase slowly rot?
No. Update dependencies as needed for security patches (which typically avoid breaking changes), other than that never update unless there is an explicit business need.
Yeah, I'm with you. I have a lot on my plate, maintaining and developing the main application I work on single-handedly, while also working on several other projects, and putting out fires elsewhere in the company as needed.
I don't have time to spend days to weeks figuring out why upgrading Tailwind to version 3 breaks the project because of (presumably) my version of create-react-app.. do I need to eject, or copy the .ts/.tsx files over to a Vite project? Do i want to fuck around with CRACO, or editing the internal monster of a webpack config file directly?
Yes, critical security updates are important, but you shouldn't just go around upgrading major versions of other packages in your production app, without the understanding that it might be an incredibly time-consuming endeavour.
I am the opposite. To me, dependencies in a project are a debt to which I regularly make my payments by keeping them up-to-date and resolving breaking changes as they arise. Allowing dependencies to fall too far out of date, in my experience, made updates — when they became necessary — too painful.
I am currently stuck on a very difficult issue because of a TypeScript upgrade. The upgrade caused a type mismatch with a dependency that wasn't previously an issue, and due to the lack of documentation on that dependency I am currently trawling through source code.
> And so you're going to lose any and all typing as your solution? I don't understand. Undocumented but typed >>> undocumented and untyped.
No documentation of types means going into source code to see what is there. Sometimes there could be multiple types that could be used for something, and it's not clear which should be used. Most libraries have clear docs to show me how to use a function, I'll take that any day over the uncertainty of which type may be correct in many places in my codebase.
> Doesn't matter. Use SWC or esbuild for sub-100ms compilation times. Your CI is a long running job due to tests and lint anyways. Nobody is writing pure uncompiled JS these days - you can't use NPM libraries that way, so there's always some (Web)pack step. I haven't seen a single developer who liked having to care about browser versions and wants to go back to that - but if you add a compilation step you get that for free and can write the latest and greatest.
Not arguing for no transpilation though browser compatibility isn't much of an issue these days unless you are using some super new features of the language (the reason is more about bundling the code together and jsx as far as I understand). I am arguing that each transpilation step adds yet more config that needs to be built, understood and maintained. TypeScript is probably the worst offender, almost as much work as maintaining another webpack config in your projects.