Community Question: Breaking Changes and Version 2!

[Rycochet]

We have several breaking changes that we could make to fix things (for instance #110), and need to decide what to do about them, so asking the community for feedback. At around 10 million weekly downloads we need to make the right decision for the future!

We are getting close to version 2 being ready for prime-time release, which has one major change¹ in access for it, but not in the behaviour of the endpoints (or at least not in a way that should break anything getting encoded).

There are three basic choice, please react to this post - and comment if you want to say something:

• 👍 Make the breaking changes, add compressXyz_legacy for compatibility.
• 👀 Make the breaking changes, and don't add any compatibility code.
• 👎 Don't break any endpoints, add compressXyz_fixed for correctness.

Note

We have a far better test suite, and it is being designed so that implementations in other languages can test against it too, so we will hopefully get a compatibility table if people write command-line wrappers for them!

Footnotes

1. The old code had require("lz-string/lib/ls-string.min.js") as an entry point, the new code is require("ls-string") (or equivalent based on your language / access of choice) - this will force people to actually look and see why they can't simply update to the latest version transparently. ↩

[Georg-Git]

Thank you for this library!!!

After a break of almost 8 years, very few people will even notice the revival and this question. 🤣

But please carry on!

[Rycochet]

@Georg-Git 10 million downloads a week on npmjs - so people will notice

[Georg-Git]

Of course - when the breaking changes will hit the npm fan. 😉
I am talking about the few answers here on github. 😉
It was pure luck that I noticed the upcoming renovations.

But I really appreciate the new team's efforts!!
Many thanks 👍

[Georg-Git]

An important and widely distributed library for compression,
and new collaborators earn over some years the trust of the owner.

And when asking for a non minified file at the end of the new build process of the upcoming version 2 this request was blocked by the new collaborators. 😏

I hope everybody had read the news about the backdoor in XZ Utils:
https://www.akamai.com/blog/security-research/critical-linux-backdoor-xz-utils-discovered-what-to-know

Interesting parallels....

@pieroxy:
I hope you still keep an eye on what is being done here in your name.

😉

EDITED:
Human communication without body language can lead to misunderstandings and there were probably too few smilies in my text.

Otherwise I would have liked to take this even further by pointing to the recent issue that Chrome is already giving a virus warning when using LZ String: #239 😊

Now seriously:
I have no indication that anything wrong is going on with this project.
But once suspicion has been triggered, counter-statements are of little use.
(And @Rycochet way of answering doesn't encourage trust either.)

Especially out of respect and gratitude to @pieroxy for this repository, I would like to avoid leaving unjustified suspicion in the room. Also, I am sure @karnthis will prevent anything like that. 😉

As already written above only a few people had taken notice of this thread after an 8-year break.
This will of course change with the release of version 2 on NPM.

Therefore, I will delete this comment soon - and wish the new version much success.

[Rycochet]

@Georg-Git Releases are planned to be directly from the Github Actions process, as in having no ability for any individual (except @pieroxy) to make a release directly. Currently you have opened and commented on several threads without having any real understanding of the open source community or apparently the npm architecture.

I am very well aware of your behaviour and suggest you (and any other readers of this comment) watch this 2008 presentation from Google https://www.youtube.com/watch?v=-F-3E8pyjFo (it really needs the entire hour to be watched to understand properly).

That suggestion was answered, and is as such closed. The source code is all here and anyone can build and test it in an identical way.

[karnthis]

@Georg-Git please don't delete your comments, they are an important part of the discussion and future readers will want to reference this down the road I'm sure.

Now to your point about a non-minified version. While I understand where you are coming from and in principle I agree transparency is critical, building a non-minified file doesn't achieve that and actually opens doors for greater harm. It is quite easy to build a minified file that has little or nothing in common with a non-minified file from the same build process, but now everyone feels safe and secure because they can review the non-minified file, leading to lax security practices. We want to encourage sustainable best practices and not foster a false sense of security.

[Rycochet]

@karnthis Thank you - far better explanation than I gave there!

[cyfung1031]

@Rycochet You should do like compress and compressToUTF16

keep everything existing remain unchanged.
just add new methods or use a flag to turn on or off V2

no need to have any breaking change.

---

for example, LZString.version = 2 or LZString.fixBase64 = true to indicate using the fixed version.
This has to be manually turned on.

Even the existing users suddenly updated the script to latest version, there should have no change as they do not turn on the setting.

[pieroxy]

I completely agree with @cyfung1031 in that there are plenty of ways to make the change non-breaking. That said, the fact that the Base64 is buggy should not bother anyone. The server side ports of this lib already handle the bug and there is no harm done. And the fact that it's proper Base64 is irrelevant

Moreover, the compressToBase64 is pretty much useless in that I don't see a valid use case for it. compressToEncodedURIComponent works fine for putting data in a URL. It is the same size and would work fine for all usages of compressToBase64.

That said, I understand the urge, it's itching me as well :-)

[pieroxy]

@Georg-Git Nothing here is done in my name, you must be confused. People own their stuff and no one claimed to have done anything in my name.

[wkrick]

@pieroxy

Moreover, the compressToBase64 is pretty much useless in that I don't see a valid use case for it. compressToEncodedURIComponent works fine for putting data in a URL. It is the same size and would work fine for all usages of compressToBase64.

There's an issue with the character set used by compressToEncodedURIComponent. Two of the characters are not URL safe...

#127

This is why I suggested adding a new compressTo method that implements the base64URL standard since it addresses the invalid characters...

More info: https://base64.guru/standards/base64url

@karnthis implemented it in their fork (compressToBase64URL / decompressFromBase64URL)...

karnthis@32e6ed1

By adding completely new methods, there's no danger of breaking backwards compatibility. Though, if it depends on having a corrected Base64 implementation, that could be a problem.

Regardless, I'd really like to see a 2.0 release some day with new methods or flags to fix bugs (or both) as suggested by @cyfung1031 . It feels like this project has stalled.