New version release plan?
HyunSeob opened this issue · 31 comments
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?
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?
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.
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?
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.
Maybe you could pull the types directly into this repo? https://www.npmjs.com/package/@types/uuid
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.
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.
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.
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.
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
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.
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).
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.
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.
I know folks are busy, but I was wondering if you had an ETA for the v9 release? Thanks in advance
Good question. 9.0.0-beta.0 has been published, and there's no open issues remaining on the v9 project board.
@ctavan: Are we just in "let it simmer for a while" mode at this point? Thoughts on when we should make it official?
I was wondering if we should try to get the TS types packed with uuid before we ship v9? However I think for this we'd have to rely on @LinusU's help. On the other hand, adding them would also not be a breaking change, so we can still ship that with 9.1.
I was also hoping to see the jest@29 release before releasing uuid@9, it's supposed to come very soon.
So let's say that we're O(days) away from v9 and not O(weeks).
uuid@9.0.0 has been released, see changelog.
It supports jest@29 out of the box again but we don't ship TypeScript types yet.
Sorry, missed the comment 25 days ago, I can submit a PR to add the types to this repo. It should be a non-breaking change so I think it could go out as 9.1?
Sounds good to me.
Hey Guys, this may be a little late (because I've just stumbled on the discussion), but as a committed TS hater I'd hate to see TS types packaged as part of the main app. If you really want them, can't you just release a different package with them?
For every TS developer, there are 3 JS developers who hate that language. Because of their instance on adding their types to our libraries, my colleagues and I now have to suffer larger libraries than I would otherwise. I know you're going to say something like, "but it's only 1 or two files," and it is, but it's an extra file or two for every one of the thousands of libs that are imported in a typical non-trivial project. Files that 3/4 of us don't want and won't use.
If the TS guys want this, and you're happy to provide it, please, provide it in a separate package, like some other libraries do. Otherwise, 3/4 of your users will have to waste even more storage so that non-javascript users can make use of your lib.
For every TS developer, there are 3 JS developers who hate that language.
Very interesting, where did you get these statistics?
It was my understanding that the benefits certainly outweighs the very small drawback of shipping an extra file. E.g. even if you don't use TypeScript, having a typings file will provide better autocomplete in your editor...
It was my understanding that the benefits certainly outweighs the very small drawback of shipping an extra file. E.g. even if you don't use TypeScript, having a typings file will provide better autocomplete in your editor...
In a personal perspective, I don't like Typescript because ads itself as a EcmaScript extension while it isn't, and it's implementation has some bugs left for historical reasons, but types are something really useful, that's why I'm desiring so much that the proposal of optional typings annotations as comments moves forward, defining types with JsDoc is painfully verbose.
If the TS guys want this, and you're happy to provide it, please, provide it in a separate package, like some other libraries do. Otherwise, 3/4 of your users will have to waste even more storage so that non-javascript users can make use of your lib.
So you'll be terribly inconvenienced by your IDE knowing the types of your dependency even when you yourself use Javascript.
If you need a super small bundle you can just use webpack/rollup - then no types get shipped with your application. Most packages ship a ton of useless data that's simply much much much larger than any typescript definitions file.
It's really quite silly what you're saying.
I understand where you're coming from, @BryanDollery. 5 years ago, I despised TS. I saw it as yet another embrace-extend-extinguish effort by M$FT. But I've since become a convert. So much so that I've been leading the effort to port CodePen's codebase to TS. I like to think this gives me a pretty good basis for having opinions on this matter.
can't you just release a different package with them?
That is how it currently works. @types/uuid has been a thing for a few years now. But there are a couple problems with that: 1) It's an additional installation step, with additional clutter in a projects package.json#dependencies, and 2) it's maintained separately by people unaffiliated with this project.
That last point is really the biggest issue. Having two separate projects defining the same API invariably causes problems.
Basically the @types project is an enormous band-aid to help with TS adoption, but it's not an ideal solution by any means.
suffer larger libraries than I would otherwise
How does that translate to actual pain for you, though? Yes, node_modules/uuid is grows slightly, but the node_modules directory is largely opaque to developers, by design.
You're going to have to do a better job articulating how the presence of type declaration files actually inhibits your ability to use uuid. At present, I'm just not seeing it.
(FWIW, the most compelling argument against TS that I've been able to come up with is that, in an open source project, it reduces the number of developers who are comfortable reviewing and writing code. But that only applies if the actual codebase is written in TS. That's not what is being proposed here, however.... yet. 😈 )
For every TS developer, there are 3 JS developers who hate that language.
Very interesting, where did you get these statistics?
It was my understanding that the benefits certainly outweighs the very small drawback of shipping an extra file. E.g. even if you don't use TypeScript, having a typings file will provide better autocomplete in your editor...
StackOverflow developer survey 2022
I understand where you're coming from, @BryanDollery. 5 years ago, I despised TS. I saw it as yet another embrace-extend-extinguish effort by M$FT. But I've since become a convert. So much so that I've been leading the effort to port CodePen's codebase to TS. I like to think this gives me a pretty good basis for having opinions on this matter.
can't you just release a different package with them?
That is how it currently works.
@types/uuidhas been a thing for a few years now. But there are a couple problems with that: 1) It's an additional installation step, with additional clutter in a projectspackage.json#dependencies, and 2) it's maintained separately by people unaffiliated with this project.That last point is really the biggest issue. Having two separate projects defining the same API invariably causes problems. Basically the
@typesproject is an enormous band-aid to help with TS adoption, but it's not an ideal solution by any means.suffer larger libraries than I would otherwise
How does that translate to actual pain for you, though? Yes,
node_modules/uuidis grows slightly, but thenode_modulesdirectory is largely opaque to developers, by design.
It's not that opaque when the size of your container images are growing by the day. It's not just uuid that's causing a problem with this solution -- it's a pandemic :) It is in aggregation that we see the problem emerging. Everyone is doing this.
My build is slowed down too because there are now extra files and dependencies I have to scan. Again, individually they might be harmless, but with this trend a large majority of us could be spending more on storage and compute than we need to at a time when we should all be doing our best to reduce such things so as to promote economic prudence and environmental sustainability.
You're going to have to do a better job articulating how the presence of type declaration files actually inhibits your ability to use
uuid. At present, I'm just not seeing it.(FWIW, the most compelling argument against TS that I've been able to come up with is that, in an open source project, it reduces the number of developers who are comfortable reviewing and writing code. But that only applies if the actual codebase is written in TS. That's not what is being proposed here, however.... yet. 😈 )
Fortunately, it doesn't stop me from using uuid (presumably).
I get that it might add some typing support for an ide, but half the time I just want to make a quick edit and open the file in vim, which I'm not going to configure as a full ide just to get that benefit.
I don't want to go into depth about why I hate TS. I have significant experience (years) with that language and know it well enough to have developed my beliefs. And, it's not important. What is important is that if this isn't a typescript project, then it doesn't need the extra baggage.
For this project though, where is the benefit? uuid produces strings, not complex classes. I've checked out the TS bindings, and they're are mind-numbing. I know that uuid does more than just produce a string, btw, but I honestly believe that 99% of people using uuid do so just to generate a unique id as a string. So, not only are you producing bindings for 1/4 of developers, you're producing them for the 1% of those guys who need to do something more complicated than simply gen a unique string id. Not worth the effort of alienating potential contributors for. Not worth the effort of further bloating my container images and slowing down my processes for.
Look, if it saves you some hassle then yeah, go ahead. I'm already grateful that you're doing this. It has saved me hours of work and I'm happy and I wouldn't want to suggest that you sign up for more effort than absolutely necessary. But, if the external lib already exists and someone else is maintaining it, then why would you go through the effort at all? The existing solution works fine for most of us already.
For every TS developer, there are 3 JS developers who hate that language.
Very interesting, where did you get these statistics?
It was my understanding that the benefits certainly outweighs the very small drawback of shipping an extra file. E.g. even if you don't use TypeScript, having a typings file will provide better autocomplete in your editor...StackOverflow developer survey 2022
https://survey.stackoverflow.co/2022/#most-loved-dreaded-and-wanted-language-love-dread
I don't see any data here that backs this up? In fact, TypeScript is more loved than JavaScript? And JavaScript more dreaded than TypeScript?
https://survey.stackoverflow.co/2022/#worked-with-vs-want-to-work-with-language-worked-want
This part also shows that more people that worked with JavaScript wants to work with TypeScript, than the number of people that worked with TypeScript and want to work with JavaScript?
As you say, @BryanDollery, TS is endemic within the NPM ecosystem. For example, when I look at node_modules in the CodePen monorepo, I find that 30% of the 1,473 modules that it pulls in have built-in TS definitions. Looking further ...
| All files | *.ts files | |
|---|---|---|
| # of files | 95,504 | 15,511 |
| logical file size {MB} | 1086 | 69 |
(File sizes tallied with find node_modules -type f -name "*.ts" | xargs stat -f "%z" | jq -s add)
By count TS is ~16% of node_modules, but by [logical] size it's < 1%. While this is anecdotal, I expect most projects of any significant size will see similar #'s. The file sizes above don't include wastage due to block allocation, so the actual impact on the fs footprint will be bigger. In our case, it turns out to be ~9%. Running find node_modules.sans_ts -type f -name "*.ts" -exec rm {} \;) reduces the overall footprint from 1.35GB to 1.23GB (per du -sh). While that's noticeable, it's still single-digits.
3/4 of your users will have to waste even more storage so that non-javascript users can make use of your lib.
For uuid, built-in TS declarations will probably be one file ~2.5kB in size. That is simply not worth worrying about. Not in the context of uuid's 100kB+ install footprint, and certainly not in the larger 100MB's footprint of most node_modules installations.
(Related: uuid has shipped with a 12kB CHANGELOG file and a 16kB README for years and nobody has ever complained about those.)
The more I think about this the more I'm convinced that this level of filesystem optimization isn't our problem to solve. Anyone this concerned with filesystem bloat should have a more holistic solution, a tool that lets them define and remove anything they deem "useless": Docs files (README, CHANGELOG, etc.), config files (travis, mocha, jest, eslint, prettier), other extraneous cruft they deem uninteresting (.DS_Store, .*~) and, yes, TS declarations.
Belated apologies for the off-topic discussion. I'm going to close this out since we've pushed uuid@9 out months ago.
If anyone wants to continue the TS-bloat conversation, please open a discussion for that and reference the conversation here.