JSCS — end of the line
JSCS 3.0 is finally out, and we are both very excited and a little sad. Excited because this new version is something that we’ve worked very hard on, and sad because this will be the last version of JSCS.
With your help, JSCS has become a success. We have over 5,000 stars on GitHub and have over 27,000 npm downloads each day. Even so, we’ve made the difficult decision to deprecate JSCS.
The Story of JSCS 3.0
This decision didn’t come easily to us, we worked very hard on JSCS 3.0, as you might notice by the long list of commits. What’s not clear from the commits is just how much additional work we (biggest thanks goes to founder of JSCS — @mdevils) put into a new project that powers JSCS: CST.
Having a working version of a CST (Concrete Syntax Tree) was incredibly important to us. The CST makes it easy to provide autofixing for the more complicated problems, such as unused variables, dead code elimination, and whatever the linter of your wildest dreams should fix. (We wrote more about CSTs in our 2.2.0 release.)
We also wrote our own CST scope analyzer, rewrote every single rule in JSCS, fixed numerous bugs, and worked hard on performance. So why put in all this work only to deprecate JSCS?
Maintenance Cost
Projects like JSCS require a lot of effort — reviewing pull requests, triaging issues, writing documentation, and maintaining a website. We also spent a lot of time (sometimes overnight) providing support via Gitter. And of course, there’s also the work of continuing to write code and tests for that code.
Maintaining JSCS takes a lot of time, and the entire team works on it in their spare time (nights and weekends) while working full-time jobs. As we’ve been seeing fewer users, contributors, and feedback, it’s gotten harder for us to continue the work.
Joining ESLint
We came to the realization that ESLint and JSCS are really solving the same set of problems in very similar ways. The community seems to want to use a single linter, and we want to help that become a reality.
We thought, why continue to “compete” with ESLint? Why we can’t we join efforts in providing the most efficient, robust, and feature-rich tool? Why not combine teams, work together, and spread out the hard work across a larger number of people?
That’s why we’re happy to share that, starting today, most of the JSCS maintainers will join the ESLint team. We will continue to support JSCS for three months fixing bugs but will not be implementing any new features. We will also continue work on the CST project, as we believe this is an important part of the JavaScript’s linting future. We hope that we can bring this goodness to ESLint itself or use our experience with it to figure out how to improve ESLint’s autofixing.
In the end of the beginning
As mentioned earlier, we will continue to support JSCS for the next three months, fixing significant bugs. The JSCS repository will be left in place, so you are free to fork it and otherwise use the code.
Moving from JSCS 2.x to 3.0 should be as easy as updating your version in `package.json`. Eventually, you’ll want to use ESLint instead. We are working with the ESLint team to create some tools and processes to make the transition as easy as possible. Our hope is that it will be a smooth upgrade and you wouldn’t even notice :).
Farewell and Thanks
We are very grateful to all the awesome contributors of this release (and previous ones). It’s because of you that JSCS reached the success that it has, and we’d like to invite you to join us in contributing to ESLint going forward.
