Misc: move jscs codebase to es6

[hzoo]

Probably with babel? One idea is to use src/ for our es6 files and 'lib/ for transformed code?

I guess there's 2 main tasks:

• refactor npm scripts for babel/es6 (coverage, etc) + test if it works!
• actually convert code to es6
  • core
  • rules
  • tests

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[mrjoelkemp]

We also need to make sure our "main" in the package.json is still valid after this effort.

[mrjoelkemp]

core to es6 is a smaller effort and quicker to merge.

[hzoo]

Would this be on master or 2.0 branch, I thought it would be harder for core since we are changing things in 2.0?

[mrjoelkemp]

This would have to be after 2.0 since all outstanding prs would need to be
es6ified then merge conflict resolved.
On Jun 19, 2015 9:15 AM, "Henry Zhu" [email protected] wrote:

Would this be on master or 2.0 branch, I thought it would be harder for
core since we are changing things in 2.0?

—
Reply to this email directly or view it on GitHub
#1469 (comment)
.

[rimunroe]

There are a lot of nice features in es2015, but how will you address the pain points of writing a transpiled Node module? Babel does produce fairly readable code, but it's still more difficult to parse than the source in my experience. Without sourcemap support it can make debugging a hassle, especially to someone unfamiliar with the project.

[qfox]

@mrjoelkemp If we gonna to make a separate src/ folder to store es2015fied files we could avoid merge conflicts. Isn't it?

[mrjoelkemp]

@rimunroe That would definitely be a problem for folks using visual debuggers. We're not the first to use babel for node tools, so I'm hopeful there's a decent solution. It's definitely something to think about though.

@zxqfox All outstanding PRs that touch core files are in ES5. If we merge them into lib (after moving to es6), then the lib and src directories will be out of sync.

[qfox]

@mrjoelkemp Ah, that way. Sure, you're right.

[rimunroe]

@mrjoelkemp I think it's also a problem just looking at stack traces in the console or while building tooling on top of jscs. I was thinking about moving an npm module to es2015 recently, but I ended up coming to the conclusion that it didn't buy me enough to justify the switch. My codebase was considerably smaller though, and I imagine you have other things to consider, but does it buy you enough to justify the potential increase in friction for users at this point in time?

[mikesherov]

Why are we moving to ES6? What are the benefits at the moment? All I'm seeing is what the challenges would be?

[mrjoelkemp]

Using es6 within JSCS is along the lines of having a .jscsrc within jscs. We gain the ability to dogfood our es6 rules and get more hands-on experience of what our es6-centric parsers currently support. Today, we're currently relying on the community to tell us what's wrong with our es6 support.

Personally (and other community members might share the sentiment), I want to write more es6 on a day to day basis to learn more about it and have it become second nature. As a module author, I'm also very curious about the process of babel-ifying a tool that's distributed on npm.

[mikesherov]

We gain the ability to dogfood our es6 rules and get more hands-on experience of what our es6-centric parsers currently support

This is a decent reason.

Personally (and other community members might share the sentiment), I want to write more es6 on a day to day basis to learn more about it

Not a reason for a project to adopt a technology.

As a module author, I'm also very curious about the process of babel-ifying a tool that's distributed on npm.

Not a reason either.

[mikesherov]

What are the potential downsides for es6?

[hzoo]

I guess some could be - effort/time to convert all current code to es6 and asking all PRs to be es6, potentially a higher barrier to entry for more contrbutors, harder debugging like @rimunroe mentioned (although I don't really like this is an issue and there's always sourcemaps - babel itself has been written in es6 for a while now).

I think adding/using es6 rules is the main benefit other than whatever benefits es6 gives like less code. Also I noticed you were using es6 in your talk @mikesherov (nice job btw)!

[mrjoelkemp]

In regards to a higher barrier to entry, only the basic rule structure would be an es6 class. We could force adherence to es6 idioms within check, but they could easily just write es5 and it'll still compile.

For jscs core, we don't get too many contributions outside a small group of us. Suffice to say, we'd all have no problem es6'ing.

Here are a few downsides (in no particular order, just a brain dump):

A potential downside/catch is that we'd have to potentially bake in the babel browser-polyfill into the browser bundle based on the es6 features that we use. Not a deal-breaker IMO.

Another downside is that we'd need more tooling around development and releasing. We'd likely avoid committing the transpiled code and transpile pre-release. We'd also need a development task runner (grunt, gulp, etc) for transpiling.

We'd have to recast the legacy code into es6 (at least the basic rule structure into a class) for a sense of uniformity. Since users copy/paste a lot, we need to make sure our tests and rules have a consistent syntax to avoid getting strictly es5 PRs.

We'd have to police the use of es7 constructs that we feel comfortable allowing/maintaining in the codebase. There's likely some babel configuration that could limit the scope of used features during transpilation.

Folks that install via a git url will have a sad time since the transpiled assets wouldn't exist. We could likely put a post-install script in place to fix that.

Will think of more potential downsides.

[qfox]

Folks that install via a git url will have a sad time since the transpiled assets wouldn't exist. We could likely put a post-install script in place to fix that.

Is there a way to run post-install only for git installation? If we will precompile releases...

[mdevils]

+1

[mdevils]

CST is already in ES6 and the code is clearer. I would like to continue developing in ES6.