pieroxy / lz-string

LZ-based compression algorithm for JavaScript

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

LZ-String port to current typescript

karnthis opened this issue · comments

I'm not sure the best way to reach out, so I am hoping this gets reviewed by someone on the team.

I have ported this project to use Typescript and modern practices, and to be compatible with Node and Vue (and Im assuming Angular and React as well). All work can be found here: https://github.com/karnthis/plzsu. I did this for my own needs, and will be maintaining it as a fork, but I wanted to know if there is interest in bringing some or all of the work back into this repo.

@karnthis How does one use your port in a modern Vue app? I'm sure it's user error on my part but neither of these imports work for me...

import { Plzsu } from '@karnthis/plzsu'

import { compress, decompress } from '@karnthis/plzsu'

See also: https://github.com/amoutonbrady/lz-string

EDIT: I think I figured it out by looking at the test in your repo. I need to import like this...

import Plzsu from '@karnthis/plzsu'

...then create an instance...

const P = new Plzsu();

I was expecting it to behave like the other port that I linked above.

This does need to be updated to TS and more modern build / release type processes - just needs time for someone to go through and do the required work (without making code changes as the previous PR) - if you wanted to update to using Vite rather than TSDX (which is effectively abandoned sadly) then I will try to take some time to review

Also - maybe for future - but default exports are bad! :-P

This does need to be updated to TS and more modern build / release type processes - just needs time for someone to go through and do the required work (without making code changes as the previous PR) - if you wanted to update to using Vite rather than TSDX (which is effectively abandoned sadly) then I will try to take some time to review

Also - maybe for future - but default exports are bad! :-P

Thanks for the link, very interesting read. Personally I find defaults annoying and often inconsistent, but I have also generally found them to be the expected baseline.

I actually wanted to port this in vite, but TSDX was explicitly called out in the discussion about moving to typescript so I gave it a shot. I think moving it over now that it is in typescript would be trivial, so I can work on that in my spare time.

I am curious about your thoughts on the minor changes I did (such as moving to Map()) and if that would be considered an unacceptable change vs a port? I did not benchmark for speed just results/compatibility with string generated by the source project as my needs are not bottlenecks by the compression speed.

@karnthis How does one use your port in a modern Vue app? I'm sure it's user error on my part but neither of these imports work for me...

import { Plzsu } from '@karnthis/plzsu'

import { compress, decompress } from '@karnthis/plzsu'

See also: https://github.com/amoutonbrady/lz-string

EDIT: I think I figured it out by looking at the test in your repo. I need to import like this...

import Plzsu from '@karnthis/plzsu'

...then create an instance...

const P = new Plzsu();

I was expecting it to behave like the other port that I linked above.

Correct! You import and create an instance. I noticed several chunks of repetitive code and chances for future optimization, and felt a persistent object instance would be ideal.

I am curious about your thoughts on the minor changes I did (such as moving to Map()) and if that would be considered an unacceptable change vs a port? I did not benchmark for speed just results/compatibility with string generated by the source project as my needs are not bottlenecks by the compression speed.

For a conversion to TS it needs to be a straight A->B conversion, with no code changes - for the simple reason that any code changes would need to be PR'd and decided on separately - changing to Map is an actual functionality change, so can't be guaranteed to be compatible output - while bugfixing something that was only noticed due to TS would be acceptable - hopefully that makes sense!

(Nothing wrong with a second PR that points straight at the first for things like Map, but check out the rather long thread here for some really nice performance updates - #98 - converting to TS would almost definitely increase the confidence in them!)

I can work up something I think. How important is legacy support? At this point I think some support needs to be dropped or the library will be held back. What is the best means of discussing decisions? The PRs I see even with recent-ish comments are years old and much has changed in that time.

Draft PR available here: #174

I can work up something I think. How important is legacy support? At this point I think some support needs to be dropped or the library will be held back. What is the best means of discussing decisions? The PRs I see even with recent-ish comments are years old and much has changed in that time.

I feel that the simple conversion is a good start, will be a major release due to Vite building it now, and that supports all the browsers that are relevant (anyone using an older browser can stick to the current 1.5.0 release even though it should be identical as it's data manipulation only) - can safely ignore the old PR as your's hits exactly what is needed for the initial update :-D

Conversion merged, let new PR ideas commence!