New collaborators and future plans

So myself, @JobLeonard, and @rquadling have recently become collaborators on here - which basically means that we’ll be helping out @pieroxy to maintain this 😃

Future plans are still to be decided, but I’ll put down a couple on here, and then others can contribute ideas and plans (link to issues etc where relevant).

Most importantly, this will always stay compatible with the other versions in different languages - though that might mean we can lead the pack in adding something new that isn’t supported everywhere else (base91 support is one such idea - #90)

My ideas in no particular order of importance:

• Improve tests. Ideally this should use TravisCI (or similar) for automatically running them and reporting back for any PR. My preference is using Jest as this also supports code coverage reports, though feedback wanted etc.
• Decide on linting rules for consistent code quality.
• Improve the package.json. This should have the commands for building / testing / linting etc in an easy to find place (npm test makes life easier etc).
• Add a Typedef file for direct Typescript support.
• Add an ES5 module for better code shaking.
• Convert to Typescript. This may be controversial, but the code looks almost identical to Javascript, and helps prevent a significant amount of errors by having strongly typed source.
• Add performance tests (possibly as part of the improved tests). It would be nice to know if changes made are improving or degrading performance.
• Close issues by either fixing or closing.
• Move the guide to this specific library onto gh_pages (within this repo) - that is specifically this page.
• Modularise all methods, and provide grouped exports per type as well as individual (for use from npm etc - see ES5 build as another use-case).

As I say, these are my own thoughts, and not been discussed with the new team (which is precisely what this issue is for) - anything confirmed will get a tick, anything rejected will get ~crossed out~, once there’s been some discussion I’ll edit this to more of a “team plans” 😃

[JobLeonard]

How about the other checkbox suggestions that we’ve got so far? Any comments to add to any of them?

I forgot to directly react to this before. Without saying anything about how to do this, I agree with each point in the first post so far.

I would also like to add:

• reorganize architecture into more logical, composable units.

This is not quite the same as just making things more modular, since that only talks about specialised modules. I mean the architecture of the compression algorithm as a whole.

For example: currently, after encoding a character to a token value, streaming the bits of this token to the output string is done within the while loop of the _compress() function. If that would be refactored into its own prototypical object that keeps track of the state of the output string, and with its own methods like stream(token, nrOfBits), it would make testing and updating the code easier.

This goes together with the TS conversion, I guess

[pieroxy]

It’s great to see how this lib is getting attention again 😃 Great work guys, I pretty much agree with everything here.

If you make a breaking change just host two libs in this repo: LZString and LZString2 of LZStringNew for example so that there is no possible confusion.

As far as patents are concerned, LZW is out of the troubled waters and the rest came out of my brain so there is no guarantee 😛