Skip to content

4.x launch #206

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
8 of 15 tasks
kvz opened this issue Dec 9, 2024 · 16 comments
Closed
8 of 15 tasks

4.x launch #206

kvz opened this issue Dec 9, 2024 · 16 comments
Assignees

Comments

@kvz
Copy link
Member

kvz commented Dec 9, 2024

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:
@mifi
Copy link
Collaborator

mifi commented Mar 17, 2025

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?

What do you mean by these or are they done?

Not sure what this means

@kvz
Copy link
Member Author

kvz commented Mar 17, 2025

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 added a commit that referenced this issue Mar 19, 2025
@mifi
Copy link
Collaborator

mifi commented Mar 19, 2025

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
Copy link
Member Author

kvz commented Mar 19, 2025

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
Copy link
Member

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
Copy link
Member Author

kvz commented Mar 19, 2025

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

@remcohaszing
Copy link
Member

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

@mifi
Copy link
Collaborator

mifi commented Mar 20, 2025

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
Copy link
Member

Yes to both.

@mifi
Copy link
Collaborator

mifi commented Mar 20, 2025

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
Copy link
Member Author

kvz commented Mar 24, 2025

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

@Xhale1
Copy link

Xhale1 commented Apr 10, 2025

Very excited to see full ESM support!

How stable would you say the 4.0.0-4 tag on npm is?

@kvz
Copy link
Member Author

kvz commented Apr 11, 2025

Not stable, and that release is still CJS too! Please bear with us a week longer :)

@remcohaszing might you still be able to sneak Changesets in here?

@mifi
Copy link
Collaborator

mifi commented Apr 11, 2025

4.0.0-5 is out

@remcohaszing
Copy link
Member

might you still be able to sneak Changesets in here?

I could, but I think this is a bit weird to do halfway. It generates links to PRs etc. Many are already merged, so they wouldn’t be picked up. I would rather do this after 4.0.0.

@kvz
Copy link
Member Author

kvz commented May 15, 2025

@kvz kvz closed this as completed May 15, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants