adobe / brackets

An open source code editor for the web, written in JavaScript, HTML and CSS.
http://brackets.io
MIT License
33.26k stars 7.63k forks source link

ES6 Support #11644

Open marcelgerber opened 9 years ago

marcelgerber commented 9 years ago

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:

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 commented 9 years ago

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: https://github.com/codemirror/CodeMirror/commit/94fc3b71e8e9f52b9239276a34658023933aac68

petetnt commented 9 years ago

:+1:

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 commented 9 years ago

+1

MiguelCastillo commented 9 years ago

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

ingorichter commented 9 years ago

+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 commented 9 years ago

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 commented 9 years ago

@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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

@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.

marcelgerber commented 9 years ago

Maybe we can outsource the switch to ESLint (and corresponding discussion) into another issue, as it's quite big a undertaking on its own?

MiguelCastillo commented 9 years ago

@MarcelGerber Yup, I think that makes sense... Let's push it over to this thread. https://github.com/adobe/brackets/pull/11693

meteormanaged commented 8 years ago

Any plans for this in the short term?

stowball commented 8 years ago

The lack of code hinting/introspection inside arrow functions is a massive blocker for me in my current role. Everything we write is in ES6 :(.

For example:

let foo;

(baz) => {
  // Hints here
}

Should provide hints for both foo and baz inside the arrow function. Also, all JS code hints seem to break in the entire app when I do something with React components.

Also, I give a million +1's for having ESLint as the default JS linter.

petetnt commented 8 years ago

@stowball Codehints work inside arrow functions for me. Have you tried the latest master (https://github.com/adobe/brackets/wiki/How-to-Hack-on-Brackets)?

The Javascript hinting should work for React components too, but there's no JSX support for Codemirror yet (see #11061), which means that HTML/React component hinting cannot be used in .jsx components

stowball commented 8 years ago

I wasn't far behind master, but just updated and still no dice. It seems brackets gives no codehints for variables defined with let and const, and nothing works inside arrow functions :(

The following code only gave me a code hint for long and bar inside of the normal function :(

var long;
let sausage;
const dog;

function (bar) {
    long; // works
    sausage;
    dog;
    bar; // works
}

(baz) => {
    long;
    sausage;
    dog;
    baz;
}
petetnt commented 8 years ago

@stowball weird, now I can repro the issue too. I thought that at least cherry picking #11569 would have at least fixed that but still the issue persists. Would be worth a try to bump tern to 0.16 and see if it's fixed.

johann-petrak commented 4 years ago

Just tried release 1.14.1 (because 1.14.2 cannot be installed on Ubuntu 20.4 with the available deb package and snap install uses this release) and noticed that a class declaration is shown as a syntax error. Is this really not something brackets understands?