LZ-string 2.0 and preceding RC

So let’s decide once and for all what we need to do to merge that pull request

Here’s a TODO list with some first thoughts, I’ll update it as the discussion evolves. It’s very elaborate, but that’s just because I like to keep it fine-grained.

Decide what to include

Suggestions:

• LZ-string “classic” - backwards compatible with 1.4.4. If it breaks on systems where 1.4.4 worked, it is a bug
• Unsafe Array version? Should it include backwards compatibility guarantee?
• a separate ES6 version? It would take me only minor tweaks to “upgrade” the current version (use Map(), etc).

Test for bugs

• Desktop
  • Edge
  • Earliest version of IE that is supported
  • Chromium
  • Firefox
  • Safari
  • Opera
• Mobile
  • Chromium
  • Firefox
  • Safari
  • Opera

Benchmarks

• Decide on body of test cases

  • static website
  • large CSS files
  • JSON files
  • a book from Project Gutenberg, like Pride & Prejudice, or In Praise of Folly
  • A realistic large body of 16-bit characters? Is there an Asian equivalent to Project Gutenberg?
  • edge-cases like the full UTF16 range, as it breaks the unsafe version

• Desktop

  • Edge
  • Earliest version of IE that is supported
  • Chromium
  • Firefox
  • Safari
  • Opera

• Mobile

  • Chromium
  • Firefox
  • Safari
  • Opera

Have a release candidate alongside current version for <period of time> to find bugs

For how long, and how do we do this on npm?

[Rycochet]

Is that ES6 versions tree-shakeable? That’s really cool though - more browsers are supporting it all the time, plus useful for Webpack / Rollup 😃

The arrow function is meant to be slightly faster than a function due to it not being a fully-featured version (ie, they are different specs, and not just in binding) - if it’s in something that’s called a lot then I’d hope it’d be different, but I’ve not seen tests so apart from that snippet of information I have no opinions (and generally compile via Babel).

We can test via BrowserStack (they give free accounts for Open Source projects) - but I’ve not written automated tests for it before, plus not sure if it can report back to a Github PR - I’ve seen something via TravisCI that implies it can be setup, but would need to look into it when I have time. In the meantime I’d say just getting a pile of automated tests together, they can always be repackaged later - better to have comprehensive automated tests that indicate functionality breaks on any PR, and some manual tests for in-browser testing.

[JobLeonard]

Test whether the bottleneck is the call to Map.has(). Not quite, but the alternative is faster on both Chrome and Firefox:

https://run.perf.zone/view/LZString-variants-14-07-2018-minified-compress-documentbodyinnerHTML-no-Maphas-1531582559384