New and Noteworthy in Javascript tooling for Orion 12.0

As noted in our Orion 12.0 announcement, a tonne of work has gone into this release of Orion.  Over 350 Bugzilla reports were fixed.  Here are some of the many things we have been working on for the JavaScript language tooling.  Expect more in-depth looks at these items in the next few weeks.

Cross-file linting

The ESLint based validation in our JavaScript tools up to Orion 11 was only focused on the single file you were editing.  No consideration was given to the rest of your project setup.  With 12.0 the linting is now aware of the other files in your workspace and the project configuration you have set up.

• no-undef: Warn when a global variable has not been defined
• no-undef-expression:  Warn when a function (member expression) has not been defined
• no-unused-vars: Warn when declared variables are not used.
• unknown-require:  Unknown required library
• type-checked-consistent-return: Discouraged inconsistent returns

So we can now in many cases tell you that you are using a function that doesn’t exist.  Especially helpful when you mistype the name or use the wrong casing.

Make the tools consumable

We have created a new API and webpack build that will package up the JavaScript tooling in one consumable bundle that can be used to drive language plugins for other IDEs, such as Brackets or Atom.

A deep-dive into the new API is coming in a subsequent blog post. To get a jump on it, we have provided two wiki pages: (1) JavaScript tools API and, (2) Building the JavaScript API.

Improved Tern integration

In Orion 12.0 we moved the remainder of our client-side services to be Tern plugins.

These new plugins include:

1. ESlint
2. Occurrences
3. Templates / templating
4. Quickfixes
5. Outlining

The move to be more Tern-centric with our features carries many benefits, but most importantly it allows us to cut down on message passing, improve memory use and make the features more portable.

ECMA 2015 support

Orion 12.0 supports all of the ECMA 2015 specification like arrow functions, import/export statements and classes.

The tooling completely understands the new language syntax with new quick fixes and code templates also being available to get you started.  The linting rules have also been updated to respect the new ECMA 2015 code patterns.

Outlining has been updated:

ECMA 2015 outlining support

Occurrences has been updated:

ECMA 2015 occurrences support

Linting has been updated:

Lint rules updated for ECMA 2015

We also support import and export statements which require the source type to be “module”. This is set through the .tern-project file – and you can use a handy quickfix to write it all for you.

Change sourceType quickfix

Support for ESLint project configuration files

Users can now include .eslintrc files in their projects.  These files can configure all of the ESLint settings that your files are validated with, including rule severities.

.eslintrc file example

When this file is present, the rule values will override any workspace settings.  If you go from editing your project to changing settings the page will warn you that an .eslintrc file is present.

Preference warning banner for .eslintrc overrides

We support other forms of ESLint configuration too, such as settings in package.json. There is a hierarchy of configuration files that you can use. Read the full details on ESLint’s configuration page.

Package.json ESlint configuration section

Support for in-project definition files

You can define and use your own definition files in your project. See the file IndexCreation.md to find out how to proceed.

Tern index file example

The tooling will include all the type information found in your definitions to improve content assist, tooltip hovers and more.

Content assist for example in-project index file

Updated third-party libraries

Most of our third-party libraries have been refreshed:

• Acorn 3.1.0
• Doctrine 1.2.1
• ESrecurse 4.1.0
• Estraverse 4.1.1
• Escope 4.2.0
• Tern 0.18.0

A notable change to our consumed library lineup is that we have discontinued use of the Esprima parser in favour of Acorn.  There are many reasons for the switch, but the main reasons are:

• Acorn has complete ECMA 2015 support (with recovery for most of it).
• We can easily extend the Acorn parser via its plugin mechanism, so there is no need to edit parser code to have our Orion customizations.
• Acorn has robust recovery support right out of the box (no more editing the parser to hack our own in).