Skip to content

Releases: pieroxy/lz-string

Typescript conversion and bundler updates

Choose a tag to compare

@Rycochet Rycochet released this 20 Jun 18:33
e51d5a3

Updated to use the best practices, with the source code being converted (1:1) to typescript.

The packages have been updated to support the latest standards for bundlers (which means no more importing directly from github) - a standard npm install lz-string will get everything and it can be import'd or require'd as needed.

Minified version

Choose a tag to compare

@Rycochet Rycochet released this 20 Jun 18:29

Updated minified version

Changed to MIT license

Choose a tag to compare

@Rycochet Rycochet released this 20 Jun 18:29
  • Specific support for angular
  • Improved typescript typings

Fix for IE6&7

Choose a tag to compare

@pieroxy pieroxy released this 25 May 21:13

Removed the use of the bracket notation for accessing chars in a string.

amd loaders code and typescript support

Choose a tag to compare

@pieroxy pieroxy released this 26 Apr 19:17
1.4.3

Prepare version 1.4.3

Bugfix in decompressFromEncodedURIComponent

Choose a tag to compare

@pieroxy pieroxy released this 25 Mar 08:34

On the server side, '+' characters are replaced by ' ' (whitespace) and the resulting string cannot be decompressed.

The fix is ugly but it works and is 100% compatible with old versions.

Uses arrays instead of strings when building the output

Choose a tag to compare

@pieroxy pieroxy released this 23 Mar 10:11

This ends up being slightly slower on some combinations of OS/Browser, but the process consumes far less memory, and the strings produced as well consumes much less memory.

Rewrite of wrappers functions to use the compression method directly

Choose a tag to compare

@pieroxy pieroxy released this 19 Feb 21:02

This avoids calling compress and then re-encoding the results in UTF-16, base64 or URIEncoded string.

As a result:

  • The compress method is slightly slower.
  • The compressToUTF16, compressToBase64 and compressToEncodedURIComponent are slightly faster (in theory).
  • Binary compatibility for decompression is still there. This means any String compressed with an old version of the library can be decompressed by this version, and any String compressed by version 1.4.0 can be decompressed by an older version.
  • Binary compatibility for compression is not guaranteed, meaning the output from this version may be different than the output produced by an older version. This is trailing characters that are useless that are now omitted.

The jsperf (Please take them to add more results and help me prove my theory):

http://jsperf.com/lzstring-1-3-8-vs-1-4-0-forcompress/2
http://jsperf.com/lzstring-1-3-8-vs-1-4-0-for-utf16
http://jsperf.com/lzstring-1-3-8-vs-1-4-0-for-base64
http://jsperf.com/lzstring-1-3-8-vs-1-4-0-for-uri-component

NOTE: Releasing this as the performaces seems good except for base64 and uri component on IE. Those don(t take too big of a hit and are designed to send the compressed data to the network (usually internet which is orders of magnitude slower than the compression algo). So I'm going with it.

Fix in decompressFromUint8Array

Choose a tag to compare

@pieroxy pieroxy released this 18 Feb 07:35
1.3.9

Prepare v1.3.9

Performance optimizations

Choose a tag to compare

@pieroxy pieroxy released this 15 Feb 19:14
1.3.8

Prepared v1.3.8