v5 requires TypeScript v4

[axelboc]

Just posting this here in case it helps somebody.

I tried upgrading to v5, but I'm getting a TypeScript error in components/generated.d.ts. This file uses the new labeled tuple elements syntax available in TS v4, so it's not compatible with the version of TypeScript I'm using (and stuck on for now), v3.9.

You may want to mention this in the release notes.

[gsimone]

@giulioz I remember you said we were fine with retrocompat with TS < 4, mind giving this a look?

[giulioz]

Well… it gets over only if the dependant software uses typescript too, but I agree, next major we could move to TS 4 since it will be well established. If you need older TS 3.x compatibility just stuck with older r3f version.

But I still don't get why we can't target an older TS version with the configuration…

[drcmda]

i think it's not a problem, just stops you from updating dependencies. don't know how others do it, but i go: ncu -u && yarn and that takes care of it. almost do it by reflex. i have to remember to turn back ts to where it used to be afterwards manually, but managing so many repos these little specifics sometimes get lost on me.

[axelboc]

There's no magic wand, unfortunately. With ncu -u your library is evergreen ... but the ecosystem is not evergreen. There could many reasons why someone might not be able to move to TS 4 or React 17 -- for instance, they could have one dependency in their project that is no longer actively maintained and takes months to upgrade. Personally, NPM gives me 10 dependency warnings if I upgrade to React 17 right now; it's not very reassuring... I could upgrade anyway, ignore the warnings and hope everything goes well, but it's not a very safe way to manage a project.

Unless you have time to check each dependency manually (which you don't), the recommended way to manage dependencies in a library is to use version ranges (~, ^, >=, etc.) and yarn upgrade. Which range expression to use depends on the dependency:

• for normal and dev dependencies, I would use ^ for stable libraries I trust (like React), and ~ for the ones that I don't trust as much or are unstable (like Three);
• for peer dependencies and for TypeScript I would use >= (or logical OR like 3.x || 4.x if you know that the library won't work with a specific major version).

With the right version ranges, yarn upgrade will then bring you 80% of security patches and bug fixes for free. Knowing when to update the version ranges in package.json is more difficult, but generally speaking I would say: don't update until you have to. What matters for a library used by thousands of projects is stability, and minor/major versions are rarely safe to use on the day they're released -- they are often followed by patch versions. Here are, in my opinion, a few good reasons to update a dependency's version range in package.json:

• when I really need a feature from a newer version in order to add value to the library;
• when a breaking change allows me to clean up a whole bunch of code and/or reduce the size of the output bundle;
• when a dependency has a security vulnerability that is resolved in a version not reached by the version range;
• when ensuring backwards compatibility for an old version of a peer dependency is no longer worth the effort;
• when an old major version of a peer dependency is no longer commonly supported by the community (projects like Create React App are good references).

[drcmda]

if you like @axelboc you could help w/ maintenance? you seem to know a lot about this stuff

[axelboc]

Hehe, happy to help from time to time with bug fixes, but ongoing maintenance is a different story ... 😅 sorry!