Publish @tus/client

[Murderlon]

Now that tus-node-server is published under the @tus npm scope, tus-js-client should follow along.

We need to:

• Release a new major version for tus-js-client which marks this npm package as deprecated. It will no longer receive updates besides security ones. This also forces people to look up the changelog and they'll find out they need to switch.
• Change package name to @tus/client and publish to npm.

[Acconut]

• Release a new major version for tus-js-client which marks this npm package as deprecated.

How does one do this? Using the npm deprecate program?

[Murderlon]

Indeed! One could argue that a new major is not needed when you deprecate, so that's up to us

[Acconut]

Ok, so I think I would do it as the following:

• Release a final patch version: [email protected], so that all current patches are available to current users
• Deprecate tus-js-client
• Release @tus/[email protected]

Does that sounds the correct plan? I do not think a major release is necessary here.

[Murderlon]

Sounds good!

[Acconut]

To be honest, I had second thoughts about this. There are a lot of examples, documentation, blog posts and resources covering tus-js-client, so changing the name would be cumbersome for new and existing users without providing much benefit for them. From my own experience, I feel how frustrating it is if the name of a dependency changes that is not frequently interacted with (frankly, I do think that most developers do not use tus-js-client very often, once it has been successfully integrated).

Yes, I do see the benefit of using the @tus scope for tus-node-server, which consists of multiple packages. But for tus-js-client that is not (yet) the case, so I don't see it as useful for this project.

I like the idea of having everything under one umbrella, but when comparing the advantages and downsides, I still think that a name change would cause unnecessary confusion for users. So I am now tending to keeping the package name as tus-js-client.

[Murderlon]

I think it might still be worth it. For two reasons:

• tus-js-client is stable, it has had many releases and has been battle tested. This means it's okay to stay longer on one version. Critical things can be backported.
• When deprecated, every single install a developer would do locally (or in CI) would show the package is deprecated with a helpful message that it now lives under @tus/client. They might not switch immediately, but surely they will at some point.

This is about a long-term strategy, to have official packages made with expertise signal that they are by having them under @tus.