Experimental rewrite: Es6 modules, BigInt, (un)parsing and validation #317
Conversation
BREAKING CHANGE: CommonJS what?
|
how far off is this from landing :D |
|
@DarylThayil: As noted, there's no set plan for landing this. This is just a my take on what the codebase for this [9-year old module] would look like if it was updated to leverage new and coming language features. I don't know that there's a lot of demand for this, either. While it does address a few of the longer-running issues we've had with uuid (ES6 modules, parsing, validation support), none of those are critical. Probably the biggest issue with this branch is the use of |
|
to be honest a standalone ESM rewrite would do wonders (without the bigint changes, as they should probably be delivered separately). if there's no plan to at least do the ESM side of things im tempted to fork for now. in its current state, uuid can't be consumed by es modules and can't be used in TS projects targeting ESM. i'd personally go as far as saying this needs to be split into a node-only build and a browser-build, possibly in separate repos. |
The service wzrd.in seems to be unmaintained for over a year now, see browserify/wzrd.in@2f7ea69 It currently throws 502 errors on all packages as reported in uuidjs#302 or https://talk.observablehq.com/t/wzrd-in-alternatives/571 As stated in uuidjs#293 (comment) there are no plans to support legacy bundlers. Instead, we may consider to go for properly standardized ES6 modules in the future as has been teased in uuidjs#317 However for the time being let's at least remove these broken instructions from the README. Closes uuidjs#176, uuidjs#302
* chore(doc): re-generate README * fix(doc): remove wzrd.in instruction from README The service wzrd.in seems to be unmaintained for over a year now, see browserify/wzrd.in@2f7ea69 It currently throws 502 errors on all packages as reported in #302 or https://talk.observablehq.com/t/wzrd-in-alternatives/571 As stated in #293 (comment) there are no plans to support legacy bundlers. Instead, we may consider to go for properly standardized ES6 modules in the future as has been teased in #317 However for the time being let's at least remove these broken instructions from the README. Closes #176, #302
|
Closing. The UUID class is interesting, maybe as a separate module in the uuidjs org or something, but not relevant to current development work. |
|
@43081j @DarylThayil @dstaley: Sorry for taking such a long time but we have finally released The master branch README already reflects the API of v7.0.0. It would be awesome to get feedback from you if this release works well for you. |
#245 and as well as some of the work we're doing over at https://github.com/bcoe/proposal-standard-module-uuid have had me playing around with what this module might look like if it was rewritten using modern ES features (ES6 modules, BigInt) and with a UUID class for parsing/unparsing and validation.
This is the work-in-progress result. (Posting this mostly because my laptop's logic board decided to crap out and enough work went into it I'd rather not risk losing it while dealing with Apple repair process.)
Feel free to comment, with the caveat that I don't have a concrete plan (yet) for merging to master here.