Road to 1.0.0

[Murderlon]

This is the mother issue for the road to 1.0.0, which marks the first semver stable release for tus-node-server.

Progress on this release happens on the 1.x branch. From now on we should carefully land things in master, as merge conflicts between the same .js and .ts files are hard to resolve. Ideally we only work on 1.x now, except for critical bugs.

Planned

• [ ] #158 + new modern tooling (@Murderlon)
• [ ] Implement proxy support. Take tusd proxy support as inspiration (@Murderlon)
  • https://github.com/tus/tus-node-server/issues/134
  • https://github.com/tus/tus-node-server/issues/59
  • https://github.com/tus/tus-node-server/issues/170
  • https://github.com/tus/tus-node-server/issues/195
• [ ] Make getOffset consistent between stores (and potentially rename the method)
• [ ] Rethink events, likely similar to tusd hooks
• [ ] https://github.com/tus/tus-node-server/issues/300
• [ ] Return 413 Request Entity Too Large when the client sends more data than reported with Upload-Length (PR)
• [ ] S3: support chunks under 5 MB.
• [ ] S3: implement buffering to prevent hitting the 10K parts limit. If we send a 500 GB file, we need to make sure we set the part size to around 52 MB in order to prevent hitting the 10K parts limit
• [ ] #61
• [ ] Rewrite the README (@Murderlon)
• [ ] Change master to main

Up for debate

• Rethink ConfigStore (issue)
• S3: add termination extension
• GCS: add termination extension

---

Opinions welcome!

[Acconut]

This roadmap looks good to me! Do you need any specific help from my side as I am assigned as well?

[Murderlon]

This roadmap looks good to me! Do you need any specific help from my side as I am assigned as well?

No I just added you for feedback and occasional questions/support :)

[mitjap]

Since we want to make as many breaking changes now rather than later, should we also extract datastores to separate packages for 1.x? (https://github.com/tus/tus-node-server/issues/61)

[Murderlon]

Yes, I was thinking about that as well but forgot to add it! Just not sure how to do package publishing. Scoped would be cleanest: @tus/server, @tus/s3-store, etc (tus-js-client -> @tus/client would also be nice). But that means tus-node-server becomes a ghost package and people would have to manually switch, of which some people may not notice the deprecation message.

The alternative is pre- or suffixing but it's less pretty: tus-node-server-s3-store.

[mitjap]

Is it too much work to have two packages for some (limited) time, one of which would be deprecated?

[Murderlon]

It's not that it is too much work but this major version would be the moment to switch. Because people would have to check what happened in the breaking change and find out that stores are now separate install and while they're add it they might as well reinstall the server. It would be less obvious to suddenly stop updating a deprecated package in a non-major, and waiting till 2.0.0 is a bit of a stretch and a mismatch with the already separated packages in 1.0.0.

I've thought about it more and I think we should switch to the @tus scope in 1.0.0 for all tus packages in the JS ecosystem (so also tus-js-client). Having a scope further signals official packages and prevents awkward naming.