ES6 Support

[marcelgerber]

As a long term goal, we should look into adding proper ES6 (ES2015) (guides: 1 2) support.
ES6 is already being used in a whole lot of applications, ranging from server-side code running on Node/io.js to client-side code transpiled with Babel and the like.

This includes:

• Updating JSLint or switching to another linter (JSHint/ESLint)

• Adding some new keywords to the JS Code Hints

  Off the top of my head, there is (in no particular order):

  • for ... of
  • let
  • const
  • class
    • ... extends
    • constructor
    • super
  • yield
  • export
  • import
    • ... as
    • ... from

• Proper Syntax Highlighting

  This is mostly CodeMirror's part, but we should make sure to pick up fixes related to ES6

• Adding ES6 support to JS Code Hints

  Marijn has just today updated his awesome Tern (see what's new) to support most of ES6's syntax. I've already tested it locally and it looks very promising. I was able to simply drop the new version in, without the need for many adaptions.

  This work will soon be part of Update Tern & Acorn #11569.

• Some changes to JSUtils

  One example is the detection of both arrow functions (example) and shorthand method definitions as object literals (example) as valid functions.

• Making sure JS Quick Edit still works the way it should

• A whole lot of testing

I'd love to hear your feedback on these points. Feel free to elaborate on them, add new ones, or simply add your two cents. You can talk about the cool new feature you saw in this cool new editor, too. Thanks!

[zaggino]

My bit -> we should support async/await - even if it's not part of ES6, as it's gaining popularity and from what I've tested, atom and code work reasonably well with it. So far I've submitted this fix for CodeMirror to fix syntax highlighting in Brackets: codemirror/codemirror5@94fc3b7

[petetnt]

👍

I have been doing ES6 stuff in Brackets for a while now and everything works fairly well.

I'd be in favor for switching default linter from JSLint to something a bit more configurable. I recently switched to ESLint (from JSHint) because of doing lots of React/JSX/ES6 stuff and it's great (minus @zaggino's great Brackets-ESLint sometimes failing to load because of #11613, hopefully that's fixed by 1.5). Is Brackets itself still linted with JSLint? There was some discussion about switching that too sometime ago which could mean that this could be a good time for that.

[danvim]

+1

[MiguelCastillo]

I have been running ternific with the latest version of tern, and autocomplete is working pretty well.

[ingorichter]

+1
The update of the default linter is on my wishlist for a loong time. I'm using eslint most of the time, because of it's flexibility.

The rest of the list looks good and makes sense to me.

[MiguelCastillo]

ESLint 1 has been out for a little bit now, so I think we should be good to move brackets over to that.

I don't see an ESLint branch. @zaggino wanna pair up on adding ESLint? I can get something started.

[zaggino]

@MiguelCastillo Not sure what do you mean by adding ESLint, Defining linting rules for Brackets core? or? I have already put together an extension https://github.com/zaggino/brackets-eslint which I use to lint my projects.

[MiguelCastillo]

It's switching from jslint/jshint to eslint. There is lots of inline jslint annotations in the source. This means switching the grunt build to eslint and creating an .eslintrc. This is a really big effort because currently the default extension for linting in brackets is jslint, and we might want to have the default linting extension based on eslint.

@ingorichter What are your thoughts on this?

[zaggino]

Ah, understood. I currently don't have much time for any big efforts, I've been dedicating free time to rewriting bracktes-git for weeks now.

[ingorichter]

I'm happy to help getting eslint as default linter for the brackets codebase. IMHO, eslint provides the most configurable linter engine that can easily replace jslint and jshint at the same time. I don't remember the subtle differences between jslint and jshint, that prevented us from using jshint. But this was a discussion many moons ago and things have improved, especially for eslint as a big contender to conquer the veterans in this field.
If we can get it to work with the codebase with less friction, that would be aweseome. It seems, that #11693 provides a good starting point. We need to make minor config changes to disable jslint as default linter in Brackets, but that is not a big deal. Let's go for it.

[petetnt]

@ingorichter the blocker moving from JSLint to JSHint was JSHint not having the options to enforce coding styles IIRC. Which is totally not an issue with ESLint which is great.

If there's anything specific about eslint that needs help with I am more than happy to contribute too.