Support for ES6?

[bricejlin]

Any plans of supporting ES6? We're working on a project that uses ES6 (through 6to5) and would love to be able to measure complexity based on that versus the converted ES5 code.

[jsoverson]

Plans come at the parser level and then the analysis level. Nothing will likely come until esprima supports es6 proper. They've stated that won't happen until the spec is ratified or at least until it fully stabilizes.

That said, there were no syntax changes proposed at the last TC39 meeting and ratification is reportedly imminent.

[jamiebuilds]

Hi @jsoverson, I'm a contributor to 6to5 (and marionette 😜). If you need any help with this let me know or feel free to stop by our gitter room.

[jsoverson]

@thejameskyle i'm expecting some new developments for javascript parsing in the next few weeks so am holding off until those settle. If you're interested in coming down to MV from SF sometime soon we could go over some of the details at Shape. Lunch is on me :-)

[jamiebuilds]

@jsoverson That sounds ominous 😜. I'd love to head down to Mountain View, I've been wanting to tour the google campus too.

[Timopheym]

+1, JSX support also will be great!

[martinmicunda]

+1

[mfpiccolo]

👍

[dcheng168]

👍

[ctumolosus]

👍

[mrichard]

+1

[alanmulhall]

👍

[ilanbiala]

Support for checking .es6/.es files will be available if #153 is merged in. Statistics and proper analysis will come later when that is ready.

[Josh-a-e]

+1

[chrisveness]

+1

[jrodl3r]

👍 for ES6 + JSX

[jamiebuilds]

@jsoverson sounds like people want this 😜

[jsoverson]

@thejameskyle yep, i'm working on v2 now which supports modular reporters. If someone wants to update v1 with es6 support, then I'm all for it. I just can't justify splitting my effort when I already have little time to work with :-/.

[barryels]

For those who don't want to wait... Here's a simple npm script to unJSXify your source, move it into a separate dir and then plato it :)

package.json:

{
    "scripts": {
        "metrics:clean": "rm -r target/metrics/*",
        "metrics:init": "npm run metrics:clean && jsx --no-cache-dir src/js target/metrics/src/js",
        "metrics": "npm run metrics:init && plato -r -d target/metrics/report -l .jshintrc -t 'App title' -x .spec.js target/metrics/src/js"
    },
    "devDependencies": {
        "plato": "^1.5.0",
        "react-tools": "^0.13.3"
    }
}

$ npm run metrics

[raido]

+1

[0xR]

Could you use https://github.com/eslint/espree instead of esprima? It looks like espree exists because esprima is slow catch up to es6.

Also: +1

[0xR]

For anyone who can't wait for es6 support: You can run babel (6to5) manually on the files and then run plato on output. You might not get the right complexity numbers because of some generated code that is not in the orignal es6 code, but it's better than nothing.

Grunt config for grunt-babel:

babel: {
  options: {},
  plato: {
    files: [
      {
        expand: true,
        cwd: 'app',
        src: ['scripts/**/*.js'],
        dest: '.tmp/plato'
      }
    ]
  }
}

Grunt config for grunt-plato:

plato: {
  options: {
    jshint: grunt.file.readJSON('.jshintrc')
  },
  quality: {
    files: {
      'plato': ['.tmp/plato/scripts/**/*.js']
    }
  }
}

Don't forget to clean the .tmp dir

clean: {
  test: {
    files: [
      {
        src: ['.tmp/plato']
      }
    ]
  }
}

[raido]

I tried that some time ago and you can actually get rid of the generated es6 code if you are willing to write your own reporter and add couple of if statements there.

[ctumolosus]

Has anyone tried piping output from babel into plato? I would like to minimize the amount of I/O operations caused by writing/reading from disk.

[MathRobin]

The problem is that Babel add a lot of complexity for its needs, you will have a not really convincing report. But it could be a great start.

[ctumolosus]

Yeah, you can also use babel's runtime option to remove the fluff from compiled files. I find it to be a good start while we wait.

[ctumolosus]

Currently, I'm going through Git history to generate a report over time. If I could stream the output from Babel into Plato it will really help me eliminate all the I/O ops.

[skawaguchi]

+1

[valeriansaliou]

+1

[wjustice]

+1

[magikMaker]

+1

[jamiebuilds]

@jsoverson Want to lock this issue? These +1s are really useless and annoying but I don't want to unsubscribe from this thread in case something does happen with it.

[miguelramos]

+1

[kaievns]

+1

[rodoabad]

Please refrain from just commenting with +1s. They don't add any meaningful discussion to the issue.

[0xR]

@rodoabad this is currently the only way to display your interest on github. I like to think this helps the developers prioritising. To avoid the clutter in the comments I would advise this chrome extension.

[jamiebuilds]

I like to think this helps the developers prioritizing.

As someone who helps maintain one of the largest github projects, no it absolutely does not help with anything. I actively delete +1s on our repositories and lock issues where people are spamming us with them. We universally hate it, so just stop.

[jsoverson]

supported by @devcrust in 1.6.0