Version 2 TODO list
Rycochet opened this issue · comments
Non-exhaustive list of things to do before 2.0.0 can come out of RC status
- Re-enable command line binary
- Cleanup code for more modular approach
- Extend and update tests to make them easier to understand
- Ensure we have full AMD support
- Enable Github Actions for release, eslint, etc
- Add "corrected" base64 endpoint (separately named endpoint for #110 )
- Add "corrected" encodedURI endpoint (separately names endpoint for #127 )
... Other issues and bugfixes can be added, however the important thing for this initial v2 release is maintaining code compatibility, more major improvements should wait for future versions (think of the v2 releases as the in-between "we might deprecate some endpoints, but they'll still exist")
a thought, GitHub actions should be added to automatically publish releases to NPM. currently the RC.0 is documented as available via npm install, which it is not.
I feel we should identify a list of which 3rd party implementations we want to test against for compatibility. other versions are listed in the readme, but are noted as may not be 100% compatible. I also have not reviewed how out of date projects may or may not be, and as 2.0 is an attempt to modernize the codebase significantly I can pretty much promise that something is going to permanently break. perhaps the solution is a legacy mode of some sort? it feels like it could be a significant duplication of code though.
final thought, I would really like to see this move to an instantiated class model. I feel it would significantly open our options, but would be a major breaking change as everyone would have to init the class now instead of directly using the import.
I was doing some poking around, and noticed that the original lzstring file had define.amd in it. I just used defaults when setting up vite, so AMD is not included. this is an easy-ish change, do we want to do that or is that legacy enough for us to drop it?
I'm wanting to set up github actions for it - had a quick look when I had time (but going to be another busy week for me!) - it did look pretty simple, but there needs to be some other things like branch protection, and requirements for eslint etc to pass before merging - all nice actions to add!
Before 2.0 final is released we definitely need to have full compatibility in there so anyone upgrading should have an pretty transparent upgrade path (with some nice @deprecated notes in the Typescript and docs appearing over time).
I'm not sure that an instantiated class would be of any benefit - there's definitely reasons to refactor the code (split into multiple files to start with), and make use of some of the lessons learnt by TS itself (read this to get an idea on what I mean).
Having a full compatibility chart makes a lot of sense - technically that comes under documentation improvements - but ensuring that we have a nice grid with ticks where features are supported would be good! Once the code is more modular than anything built & bundled can use tree-shaking to only include the parts that are wanted, and tests mean maintaining compatibility should be easier :-)
If you're adding a corrected endpoint for base64, how do you feel about a new corrected endpoint for compressToEncodedURIComponent?
Added to the list - if anyone finds any other issues that are worth putting into the non-breaking update then do shout! :-D
hey there! i'm using lz-string in a vite project, and I'd love an rc to get published to npm so I can test es modules. any chance you'd publish the 2.0.0 release candidates?
You can clone the repo and build locally to create a local pack.
I would like to propose that a v2 branch is created, so that work on this list can be pushed via pr to it in chunks, and then a full pr can be made from the v2 branch to main. what do you think @Rycochet ?
Sorry - been really busy again - the benefit of having another branch is that it separates it, the drawback is that people try to PR based on old and (soon-to-be) unsupported code - I'm wanting to get the release process finished so things are automatic, and then the v2 release is fully public and incremental before it goes final, which is a lot easier on a single main branch :-)
Where are we on this? do we still want to update all the release processes first, or make a v2 branch until that is done?
Where are we on this? do we still want to update all the release processes first, or make a v2 branch until that is done?
I've been hit by a major lack of time for personal projects - but will get back to this when I get that time back!
Version 2 is basically the typescript update, and is live now - although I've not managed to push it out to npmjs yet - it's on my list to get the auto-build & release sorted out via github actions (but not used them before so need to be able to dedicate time to learning and confirming rather than just configuring and hoping) ;-)
I've been hit by a major lack of time for personal projects - but will get back to this when I get that time back!
I completely understand not having time for personal projects. What can I do to help? I don't want you to be in a position where you have to do everything.
I completely understand not having time for personal projects. What can I do to help? I don't want you to be in a position where you have to do everything.
Look at the list at the top of this issue, and the open issues / PRs, and see what can be implemented as PRs - review PRs and comment on issues that need it, and generally make yourself part of the community (pretty much all of us got noticed for doing that lol)
Regarding the 'Add "corrected" encodedURI endpoint' item, there's already an RFC for a Base64URL encoding scheme that I referenced in a comment on a different PR. I think we should be compatible with that if possible...
I'm not sure if @r0b- is still working on that PR or if a new PR needs to be created.
@wkrick Looks good - another endpoint ftw! :-)