New version release plan?

[HyunSeob]

It's been almost a year since the last release, so I wonder when the new version will be released. Is there any plan for release?

[ctavan]

This library is very solid and generally a rather complete implementation of RFC 4122.

What features or improvements would you be looking for in a new release?

[HyunSeob]

Thank you for the response!

When I use this package with my Next.js project, the warning message like Anonymous function declarations cause Fast Refresh to not preserve local component state. is printed out. So I think it would be nice that PR #545 is released.

[ctavan]

Thanks for pointing this out again. Looks like we should make a new release soon then.

@broofa do you think we should craft a patched 8.x release that contains the specific bug fix or would you go for 9.0 directly (as node 8 support was dropped)?

Maybe for 9.0 we could create a list of things we want to include (like dropping IE 11 support), to not have too many major version bumps?

[broofa]

Let's roll a 9.0 release. Enough stuff has changed. See https://github.com/uuidjs/uuid/projects/1 for tasks and status of this release.

[Rush]

Maybe you could pull the types directly into this repo? https://www.npmjs.com/package/@types/uuid

[ctavan]

Maybe you could pull the types directly into this repo? https://www.npmjs.com/package/@types/uuid

According to the typescript documentation this is still not recommended for packages that don’t auto-generate the typescript declarations: https://www.typescriptlang.org/docs/handbook/declaration-files/publishing.html

I would prefer following the official typescript guidance and keep the types separate.

[TrySound]

This is usually meant for those who add types and does not maintain them. For consumer this is burden to add one more package with possibly outdated types (this is the feeling I always have about any @types/* package).

For this project I don't see an issue in improving DX.

[ctavan]

This is usually meant for those who add types and does not maintain them. For consumer this is burden to add one more package with possibly outdated types (this is the feeling I always have about any @types/* package).

For this project I don't see an issue in improving DX.

I.e. you would prefer to have the types shipped directly with the uuid package?

My main concern is that I'm personally not a TypeScript expert so I don't feel comfortable maintaining/supporting the types. I think we would at least need a soft commitment from some TypeScript-aware contributors (you, @TrySound ? And maybe @LinusU ?) to provide support, if we wanted to ship them with the npm package.

[broofa]

I've created the Version 9 project to track tasks for this upcoming release.

Re: TS types, I'm in favor of that, but as @ctavan says we need someone on the team to own that. While I've been doing more work in the TS space of late, and could probably whip something together, I'm not confident that it would be well enough baked to not require ongoing maintenance, which I don't currently have the bandwidth for.

[LinusU]

I'm open to owning the TS types, but I think that before we commit to it we should see how it integrates with our somewhat complex situation with shipping multiple different versions (ESM/browser/CJS) of the library.

It seems like TS supports placing a "types" key in the "exports" map, next to e.g. "node" and "default", but we are also using main, module, and browser. This might be a non-issue but we should probably just check how the setup would look ☺️

It would also be amazing to have some kind of tests that they are in sync, but I'm not sure how that would look 🤔

One approach is to generate the typings using --allowJS and TSDoc comments. If that's feasible with our setup I think it would be the best approach, I can take a look at prototyping this!

---

btw. for the next major version I think we should investigate just shipping ESM. I'm thinking that the shipped package just have node.js and browser.js and just uses the exports field in package.json. All supported Node.js versions already have support, we just need to make sure that that works with rollup/webpack/etc ☺️

[jasonwilliams]

If you’re dropping IE 11 it might be worth dropping old node versions too. Node 10 is no longer supported by node itself, and 12 is also quite old now.

[ctavan]

If you’re dropping IE 11 it might be worth dropping old node versions too. Node 10 is no longer supported by node itself, and 12 is also quite old now.

So far we have always been supporting Node LTS versions plus one older version. I think we should keep up with this given the abundant use of this library in the Node.js world. Except for ESM, I don't see anything in this library that is incompatible with Node.js 10.x, so there's also not a big benefit of dropping Node.js 10.x support (except for maybe ESM, but I feel like this is a larger discussion).

[jasonwilliams]

If you’re dropping IE 11 it might be worth dropping old node versions too. Node 10 is no longer supported by node itself, and 12 is also quite old now.

So far we have always been supporting Node LTS versions plus one older version. I think we should keep up with this given the abundant use of this library in the Node.js world. Except for ESM, I don't see anything in this library that is incompatible with Node.js 10.x, so there's also not a big benefit of dropping Node.js 10.x support (except for maybe ESM, but I feel like this is a larger discussion).

Active LTS is v16, maintenance LTS is v14, if you went one version older it would be v12. So by that rule v10 would still be be dropped, (I suppose you could argue 12 is still LTS until early next year). I’m not saying you need to drop it, but it’s usually unhealthy having to support so many versions at the same time.

[ctavan]

According to https://nodejs.org/en/about/releases/ v12 is still in Maintenance until May 2022. With "old" I intended to say "officially unsupported". That currently applies to v10.