4.x launch

[kvz]

TODO

• TypeScript port (already in main)
• Remove isResumable (always use tus) (@mifi) remove isResumable option #209
• Add Loose just strict Robot schemas/types so consuming devs have autocomplete for Assembly Instructions when they use the Node SDK without TypeScript erroring out if they use a new FFmpeg stack version that their types didn’t know about yet (@remcohaszing)
• Add better errors (may mean vendoring Got? Do whatever is easiest & safe that will get us better errors. We'll revise this in 5.x most likely) (@mifi)
• Get an RC out to test the experience on the consuming side (@remcohaszing)
• ESM port rewrite to esm and upgrade packages #223
• Bump all dependencies #155
• upgrade content repo with it, etc (@kvz)
• Final kinks (@kvz)
• Release 4.0 (@kvz)
• Ping @Acconut, he wants to use the Smart CDN sig auth that is now also released (@kvz)

We're saving these for post-4.x. Explicitly not doing yet:

• Add changesets for auto releases (@remcohaszing)
• Switch from Prettier+ESlint+Babel to Biome (@kvz)
• Handle progress for all the runtimes in tus-js-client, so we can then:
  • Release multi-runtime support (edge, deno, browser, node, etc) (or @transloadit/client) Support for different runtimes #199

[mifi]

I'm taking over this, and have a few questions @remcohaszing @kvz:

• Add Loose just strict Robot schemas/types so consuming devs have autocomplete for Assembly Instructions when they use the Node SDK without TypeScript erroring out if they use a new FFmpeg stack version that their types didn’t know about yet (@remcohaszing)

This is done, right?

• Add changesets for auto releases (@remcohaszing)
• Final kinks (@remcohaszing)

What do you mean by these or are they done?

• Ping @Acconut, he wants to use the Smart CDN sig auth that is now also released (@remcohaszing)

Not sure what this means

[kvz]

This is done, right?

We have strict schemas in this repo. For inputs from customers, we have to use z.input instead of z.infer some types are already exposed like that, but not all I don't think. /cc @remcohaszing

changesets

Changesets was done i think 🤔

Not sure what this means

When we have released node-sdk, @Acconut wants to know. He can then update the documentation to refer to a signature calculation function that is then also part of a release.

[mifi]

I have now implemented types for the API methods, and integrated alphalib types to assembly / template instructions.

Note that I've manually modified alpha lib with a change: bd63c1c

Also note: The api2 types that I could not find in alphalib, I've typed manually and put inside https://github.com/transloadit/node-sdk/blob/main/src/apiTypes.ts - however I think they are not entirely correct, because I cannot find any typescript definitions for the API signatures, and what's documented in the API docs is not comprensive and some of it is not consistent with reality (actual responses from API endpoints). I think ideally we'd use the same schema in api2 and we use those schema to generate API docs, but that's a future task. This means that some of the types that I guessed are probably wrong. Feel free to have a look at them.

I've made a pre-release 4.0.0-4 which we can dogfood and test.

[kvz]

Really nice work Mikael! I agree those api endpoint types should be coming from the api2 repo. That's the next task after nailing Assembly Instructions I think. But let's ship the latter first, and keep the guesswork for those in the 4.x release or it will be delayed for months I think.

I have added to my todo to dogfood 4.0.0-0 and will also sync back the alphalib change. Although maybe we can be a little bit more restrictive than any. @remcohaszing what are your feels regarding all this?

[remcohaszing]

I think the schema types are still a bit premature to include. Also it could be done in a non-breaking release later. Improved types wouldn’t be a breaking change. For now I’d stick with any / unknown.

With Node.js 18 almost being EOL and require(esm) being backported to Node.js 20, we could conider fully going ESM.

[kvz]

I'm open to that, if all the exports are named vs default. We have that?

[remcohaszing]

Yes. CJS export = syntax was already problematic with Vitest, so we migrated everything to named exports in #187

[mifi]

I think the schema types are still a bit premature to include. Also it could be done in a non-breaking release later. Improved types wouldn’t be a breaking change. For now I’d stick with any / unknown.

you mean alphalib aren't mature enough for this release?

With Node.js 18 almost being EOL and require(esm) being backported to Node.js 20, we could conider fully going ESM.

so let's rewrite it to ESM and upgrade all deps before v4, do we agree on that?

[remcohaszing]

Yes to both.

[mifi]

Ok, if @kvz agrees too then i'll go ahead and

• rewrite it to esm
• rip out all references to alphalib and replace them with any. should we do it for both request arguments and server responses or only for request arguments? we will release with the schema types in its current state
• test all types (also self-guessed types) against api2

[kvz]

Yes talked about this in Slack and I think we should ship all the types we have. figured-out ones, robot schemas, etc. It's not perfect yet, and we'll do a few more passes to get them better, see also:

• test all types (also self-guessed types) against api2

but people can always @ts-expect-error if they run into things, report them, and we'll fix them. I think it's time to ship