Announcing Orion 13

We are pleased to announce the thirteenth release of Orion, “Your IDE in the Cloud”. You can run it now on OrionHub or download the server to run your own instance. Once again, thank you to all committers and contributors for your hard work this release.  There were over 180 bugs and enhancements fixed, across more than 350 commits from 13 authors!

What’s new in Orion 13?  The Orion 13 release continues to emphasize our language tooling.  In particular, we now have code formatting, support for .jsbeautifyrc files and full ECMA 2016 support.  We have also been investigating LSP and have some experimental work in place to support Java, but this is not yet generally available.

The other focus of this release is consumability and accessibility. To make Orion easier to use for end users, admins and everyone in between, we substantially improved the node.js server (which is used on or locally), created an experimental Electron app version of Orion, improved accessibility, enabled custom code folding in the code edit widget and a whole lot more!


Posted in Announcements | Tagged , , | 2 Comments

Google Cloud Shell adopts the Orion Code Editor

It’s nice to see Google Cloud Shell using Orion in their latest offering. Google Cloud Shell is just that: a shell (really a bunch of shells) to a machine in the cloud. The machine contains source files (go figure) and Orion is great at editing files, syntax coloring, code assist, refactoring, dynamic linting and much more.

This is how you get to Orion in Cloud Shell:


Here is Orion running in Google Platform Shell:


I am reminded that IBM makes extensive use of Orion as a code editor in Bluemix DevOps Services and that we should really blog about that again soon.  Development in the cloud for the cloud!


Posted in General | Comments Off on Google Cloud Shell adopts the Orion Code Editor

New and noteworthy for codeEdit widget 12

Orion codeEdit widget debuted just one year ago in Orion 9.0. Thanks to all the valuable user feedback over the past year, now in Orion 12, the widget has been improved a lot for both usability and customizability. We’ve updated the widget wiki page to include the latest features, summarizing user feedback in the FAQ section.

The codeEdit demo page shows you two of the biggest improvements in the widget: customizable editor configurations and fine tuning your web language tooling. In Orion 11.0 we introduced tern project – now this feature is integrated into the widget. In the demo you will see a zoom ruler in each editor, enabled by an editor configuration change. You will also see how the javascript file validation behavior changes while live editing the tern project and eslint rule files.

Aside from that, there are other major improvements that are not shown in the demo.

With all the improvements so far, we found it’s been much easier for the existing users to consume and customize the widget. We are still improving in other areas so please stay tuned.

Posted in General | 1 Comment

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

ECMA 2015 outlining support

Occurrences has been updated:

ECMA 2015 occurrences support

ECMA 2015 occurrences support

Linting has been updated:

Lint rules updated for ECMA 2015

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

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

.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

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

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 to find out how to proceed.

Tern index file example

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

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).
Posted in New & Noteworthy | Tagged , , , , | 1 Comment

Announcing Orion 12

We are pleased to announce the twelfth release of Orion, “Your IDE in the Cloud”. You can run it now on OrionHub or download the server to run your own instance. Once again, thank you to all committers and contributors for your hard work this release.  There were over 350 bugs and enhancements fixed, across more than 900 commits from 22 authors!

What’s new in Orion 12?  The Orion 12 release continues to emphasize our JavaScript tooling.  In particular, we now have full support for the ECMA 2015 spec, vastly improved project configuration capabilities, support for eslintrc.* files and much much more!

The other focus of this release is consumability. To make Orion easier to use for end users, admins and everyone in between, we created an experimental node.js server (which can be used on or locally), a metrics service for plugins, some super cool updates to the code edit widget and a whole lot more!


Posted in Announcements | Tagged , , | 1 Comment

Configuring your Orion project

Everyone loves to customize stuff.

In Orion 11.0, we provided support for .tern-project files so you can do just that. A .tern-project file, for those unfamiliar with them, is a configuration file that lives at the root of your project, is entirely JSON, and tells Tern how and what to run with.

Lets see an example file (the one used in the Orion client):

  "plugins": {
    "node": {},
    "requirejs": {},
    "express": {}
  "ecmaVersion": 5,
  "libs": [

See? It’s not so bad. Now lets talk about what all the parts mean, and why you would want to make one.

The first thing typically asked when talking about these files and configuring your project is: “what if I don’t have a .tern-project file?”. The short answer is; we start Tern with a default configuration that contains every plugin we pre-package in Orion.

The longer answer is:

  1. you get all of the required core services plugins from Orion (like HTML support, parsing plugins, etc)
  2. you get all of the pre-packaged plugins (mongodb, redis, mysql, express, amqp, postgres, node, requirejs and angular)
  3. you get a default ECMA parse level of 6
  4. you get a default set of definitions (ecma5, ecma6, browser and chai)

Basically, everything will work right out of the box, the downside is that you get a lot more stuff loaded in Tern than you might need (or want).


This is the most common element that people create a .tern-project file for, and its an easy one. If you are coding against ECMA 6, the defaults are fine. If you are not, its best to change this to be 5.


This entry describes type libraries you want Tern to use. These libraries provide type information that is used for content assist and inferencing. At the moment, only the definitions that come pre-packaged in Orion can be entered in this list, which include  ecma5, ecma6, browser and chai.

I know what you are thinking. What if I have a definition not in the list I would like to use? We are working on support for custom definition files directly in the project, and providing a UI to install new ones.


This entry describes all of the plugins that you want Tern to run with. As mentioned, by default you get everything. Leave it out? You get everything. Empty plugins entry? You get everything.

Regardless of what you put in the plugins entry, you will always get the core services plugins that Orion needs to function – so no, you cannot break the tools.

While everything will work fine right out of the box with all plugins running – you can really improve the performance and memory usage of the tools if you tell us what support you actually need. For example, working on a node.js project? only include the node plugin. Working on AMD browser project? only include the requirejs plugin. You get the idea – only load what you actually need.

At the moment, the list of plugins that can be enabled is amqp, angular, express, mongodb, mysql, node, postgres, redis, requirejs. And yes, we are working on ways to provide your own.


This entry is a list of files that are so important, that you just have to have Tern load them when it starts up. All joking aside, this entry is best for pointing Tern at the ‘main’ in your project. For example, say you were working on a web page. You could add index.html in the loadEagerly entry to have Tern automatically load that file and all the dependent scripts right away, so everything was primed and ready to go immediately (as opposed to Tern filling in its type information as you open and close files).


Don’t change this entry. Set too low, it will cause dependency resolution to time out (incomplete type information). Set too high, the IDE will wait longer before answering whatever you asked it (content assist, open decl, etc).

So thats it. Those are all of the supported entries that can appear in the .tern-project file. A pretty short list.

You can’t break the tools by setting a bad entry – we have sanity checking that will revert to a “something is wrong, load the defaults” state. We also have linting / sanity checking that will alert you if you have broken something in the file.

Tern project file linting

Tern project file linting

Broke the file and still navigated to another file (or maybe brought in a change from git that broke the file)? We will alert you that its bad in the banner, with a handy link to jump to the file and fix it!

Tern project file banner message

Tern project file banner message

Remember, you can ignore all the warnings (if you really want to) and Tern will still start with the defaults as a safety measure.

Feeling a bit lazy and don’t want to type out a brand new file for your project? Just open up the new (empty) .tern-project and hit Ctrl+Space, which will auto-magically insert a shiny new template for you.

Happy configuring!

Posted in General | Tagged , , , | Comments Off on Configuring your Orion project

Your code has mistakes – We can help you fix them

Orion has powerful linting tools that detect potential programming problems as you type.  Our tooling provides a huge list of rules, everything from basic syntax mistakes like missing semicolons to multi-file function reference checking.  Try out the latest at

The linting tools are based on ESLint, but we have our own set of rule implementations.  These rules are used to test the code in your editor as you type.  Discovered issues are marked with annotations, squiggly yellow or red underlines reminiscent of Eclipse.


Hovering over the annotation will give you a tooltip hover with a description of the problem.  In addition the hover may show buttons representing quick fixes.  Quick fixes modify your code to fix the linting problem.  While no quick fix should ever break your code, you can always undo the effects (Ctrl+Z).  Most fixes will automatically fix the code, adding or removing content, but a few will start a rename operation requiring you to type a new name.



Some quick fixes also have a ‘Fix All’ option which will fix all instances of that problem in your file.


Our rule list continues to expand.  We have incorporated rule implementations from ESLint, added rules specific to our translations support, and now we are working at writing rules that use our type inference engine to detect reference problems between scripts.


If a rule goes against the programming practices your dev team follows, you can change which rules run on the JavaScript Validation settings page.


If you want to run a linting pass on multiple files you can use the Show Problems command.  Select a file or folder in the file navigator, right click and press Show Problems… (Ctrl+Alt+P).  This will run the linter on all of the files and display them in a table.  You can click on any problem to navigate to it.




Posted in Tips & Tricks | Comments Off on Your code has mistakes – We can help you fix them

What is new and awesome in Orion 11.0

With Orion 11.0 officially released, it is time again to share with you the new & noteworthy items developed during this release.  Unlike previous announcements we will be posting more in-depth articles about the new functionality and how to use it.


Where is this function used?  Where is it declared?  What if I need to change its signature? Global search is not the only tool for answering these questions if you use Orion 11.0.  Find All References can search through your project or workspace find potential matches and then figure out which ones are actually referencing the function (or variable) you are interested in.  Orion will sort all the matches into reference types and then provide a green check if we are sure this is a matching reference, a question mark if it is a possible reference, or a red X if it is not a reference (but matches the search text).  You can take it a step further and refactor the contents of multiple files at once.  There is a full write-up on Planet Orion with the details.


Documentation of your APIs not only is good practice, it makes the existing language tools work better.  When your JSDoc (add it to any function using Alt+Shift+J) specifies the type of a function’s arguments and returns, the tooling can offer more accurate content assist and hovers.  To help you fill in these types we now offer content assist inside JSDoc.


Our JavaScript linting (based on the ESLint validator) continues to expand with new rules, new quick fixes and more.  Remember that all of the rules can have their severity configured on the JavaScript Validation settings page.  The excited new feature for 11.0 is ‘fix all’, applying quick fixes to the entire file.  Open up a file with warnings throughout and quickly apply safe fixes to clean up the whole file.  There is a lot happening in our validation support during this release and the next, so we will have a more in-depth look at the features in an upcoming article.



Many of the JavaScript tools work closely with our type inferencing engine, Tern.  To get the most accurate content assist, correct navigation and detailed hovers it is best to have your project set up in a way Tern can easily analyze your code.  The best way to provide our tooling and Tern with this information is through creation of a .tern-project file.  In the coming weeks we will give a full write-up on how to do this and exactly how it will benefit your project.


Our tooling for HTML has seen impressive improvements during this release.  The parser we use was entirely replaced with HTMLParser2 providing us with much more accurate ranges and more recovery options for incomplete HTML.  Content assist has expanded to support accessibility attributes, specifically ARIA roles.  We also provide assist for many attribute values, not just the elements and attributes.  See the full write up here.


We also highlight the selected tag and its matching tag close.  Have Show Occurrences option turned on in the Editor Settings to see it.

The Orion client continues to improve each release.  There were more than 150 bugs fixed during 11.0.  We have updated the libraries that we depend on to pick up their hard work:   Acorn 2.6.4 Doctrine 0.7.1 Estraverse 4.1.1 ESLint 1.9.0.  Our test suites continue to expand, the shining example being JavaScript tools which has 2232 tests and growing.

Try it right now at!


Posted in New & Noteworthy | Comments Off on What is new and awesome in Orion 11.0

Announcing Orion 11

We are pleased to announce the eleventh release of Orion, “Your IDE in the Cloud”. You can run it now on OrionHub or download the server to run your own instance. Once again, thanks to all committers and contributors for your hard work.  There were 163 bugs and enhancements fixed, across 435 commits from 21 authors! Thank you to everyone for your hard work this release.

What’s new in Orion 11?  The Orion 11 release continues to emphasize our JavaScript tooling.  In particular, the new References feature allows you to quickly browse and refactor your code.  Think of this capability as a kind of structured search: It finds raw references, then categorizes and weighs them based on how well they match your initial search and finally, provides a prioritized view for you to browse and edit.

Another area in Orion 11 that was improved was git page.  Support for pull requests and the “train tracks” (git merge/branch history) view was added.

Finally, we’ve improved our accessibility support to make it easier for you to write accessible code on the web.


Posted in Announcements, New & Noteworthy | 2 Comments

What the heck does this code do? Find out before you refactor

A common problem for developers is being able to work effectively with and understand large code bases. This problem can affect everyone on a team, whether you’re new or experienced. It’s hard to know every line, and everyone needs to find their way around the code base.

Better not refactor!

Refactoring JavaScript code can be intimidating, so many developers avoid it. Over time, they write code to fix bugs and implement features, and the code base grows. As it grows, it becomes harder to maintain. At the same time, team members with tribal knowledge leave and others come on board. The technical debt grows and grows.

Orion to the rescue

Imagine that you’re browsing a code base and you see a function call. You might ask yourself:

“Where is this function defined? Are there multiple declarations? Who else uses this thing? If I change the implementation, who is affected?”

Fortunately, Orion has a new feature to help in this scenario. It’s called “References.” To use it, click a code element, such as a function call, and select an option from the References menu:

Web IDE with References menu selected

A window opens to show each match, categorized and weighted:

References window, showing categories


In the window, you can browse by category to focus on the most important matches first. For example, “Function Declarations” and “Function Calls” are important and interesting categories. If a category doesn’t contain any matches, the category is not shown. All matches are categorized, including those that occur in comments and strings. In JavaScript, strings can be evaluated (don’t do this) and JSDoc contains valuable information.


Orion includes a type-inference engine that can determine the type and scope of a function or variable. This information is used to weigh the results.

Here is a handy legend:

  • Green check mark: Perfect match
  • Blue question mark (?): Potential match
  • Red (x): Not a match

Go ahead and refactor

It’s no accident that the user interface (UI) for the References feature looks like the UI for the Global Search feature. When you’re wondering how a function is used, you need to see the calls and declarations, but you also need more information. JavaScript is a dynamic language where strings can be evaluated and functions can be saved in properties and then called or even passed around as arguments. A function can be used in meta programming; you need to be aware of that when you refactor.

You can refactor the references that you found to the main() function to be main2() by clicking Preview:

References window, showing replacements

A simple rename consists of these actions:

  1. Finding all of the references
  2. Inspecting each reference by category, noting any checks and question marks
  3. Selecting or clearing the replacement check box
  4. Clicking Replace

Of course, refactoring is more than renaming, but the first step is to find and categorize each match.


You can use the new References feature in Orion to understand how a variable or function is being used. Understanding the code is the first necessary step towards refactoring.


Posted in General | Comments Off on What the heck does this code do? Find out before you refactor