IntelliJ IDEA Scala plugin 2017.2: SBT 1.0, improved SBT Shell, Play 2.6 and better implicits management

This summer, we are happy to announce a number of new features and improvements in the Scala Plugin. Some of them we decided to introduce in the 2017.1 updates, as soon as they were ready. And the rest are coming to you now – with IntelliJ IDEA 2017.2. We appreciate the contributions of all EAP participants. So, let’s do a brief overview of the recent changes.

Debugging in SBT Shell

Not so long ago we introduced SBT Shell which makes work with SBT project in IntelliJ IDEA more convenient. We continued to improve this feature and can now announce its integration with debugger. With one button click the SBT Shell launches the Debugger server and connects to it.SBT_Debug

Before debugging, just make sure you’ve run the Debugger server via a click on the left-side panel in SBT Shell.

Play 2.6 support

Play Framework recently released its 2.6 version with lots of cool features. We’ve provided support for all this new functionality via gutter icons, code highlighting, navigation and project wizard to make your work more comfortable and effective.


Implicits management

We’ve improved the Type Annotations inspection by including implicit declarations processing. Any implicit is worth being explicitly annotated. It significantly increases the performance of compilation and IDE code analysis. It reduces the risk of a type inconsistency. Moreover it’s obligatorily in Dotty. You can configure this inspection by going to Preferences / Editor / Code Style / Scala / Type Annotations.


Another feature – if you call Smart Completion for following types:, scala.concurrent.Future and collections from java.util, scala.collection, it also suggests implicit conversions, and adds import statements automatically:


SBT 1.0 support

In the middle of July, Lightbend announced SBT 1.0.0-RC2. A list of new features, fixes, and other changes you may find here. We keep track of SBT 1.0 progress and support of all its new functionality. The Scala Plugin 2017.2.5 already has partial support of SBT 1.0 RC2, and we have plans to declare complete support in newest plugin update.

Your feedback on these improvements is very welcome. Expect more features and improvements in the 2017.2 updates of the IntelliJ Scala plugin.

P.S: Don’t forget to report bugs / ideas to our issue tracker.

Drive to develop!

Posted in New Features, Release report | 15 Comments

IntelliJ IDEA Scala plugin 2017.1.19: simplified Project View, ScalaTest selection by regexp, improved Akka support

After IntelliJ IDEA 2017.1 was released, we have added many new features to the Scala plugin.

Project View is simplified

We have reworked and simplified navigation to Scala nodes:

  • IDEA 2017-like icon style
  • Type + Companion object nodes
  • Flat package object
  • Files are leaf nodes

To explore the internal structure of a file, enable the “Show Members” parameter in Project View options:


Besides, we provide a View / Tool Window / Structure panel to see the structure of files opened in the editor:

UPDATE: a note about migration to the new scheme

Error highlighting in Project View

We have added error highlighting to Project View. The feature is disabled by default, but you can turn it on by going to Preferences / Languages & Frameworks / Scala / Project View / Highlight nodes with errors:


ScalaTest selection by RegExp

We have introduced a new kind of test suite selection: regular expression. It is now easier and more flexible to designate an exact set of tests in a particular Run Configuration. Here’s how we can filter tests with names that match “.*Phone” and with class names that match “.*UserDataTest”:


New features in Akka support

We’ve added a couple of new features to Akka support in the Ultimate version of the Scala plugin. Now we can highlight dynamic invocations that can be replaced with a constructor call:


Besides, the refactoring can suggest a system name as a candidate:


Your feedback on these improvements is very welcomed. Expect more features and improvements in the upcoming 2017.2 release of the IntelliJ Scala plugin.

P.S: Don’t forget to report bugs you find directly into our issue tracker.

Develop with Pleasure!

Posted in New Features, Release report | Tagged , , , | 7 Comments

Scala plugin for IntelliJ IDEA 2017.1: Cleaner UI, SBT shell, REPL worksheet, Akka support and more

This update brings many new features and improvements in different areas:

1. User interface

First, we’ve streamlined the project wizard:

Project Wizard

  • IDEA / SBT project formats are now clearly separated.
  • SBT project is now the default format.
  • There’s a brand-new SBT icon!

Next, we’ve simplified the wizard settings (which is especially important for novice users):

Project Settings

The handling of Dotty is upgraded:

Dotty Selection

  • Dotty SDK is now just a subtype of Scala SDK.
  • It’s possible to create / import SBT Dotty projects.

Now you can paste Scala code directly into the Project View, for example you can copy the following text:

…and paste it into the project tree – and the new Scala file with a proper name and a package statement will be created automatically. “Stack Overflow driven development” has never been easier! :)

Paste Class

Last but not least, we’ve reworked all the refactoring / code generation dialogs to make them uniform and easier to use.

2. SBT support

We’ve added a built-in SBT shell, which can be started via the SBT tool window. Autocomplete makes it easier to run SBT commands:

SBT shell

You can also run SBT tasks directly from the SBT tool window:

SBT Tasks

It’s now possible to build projects using SBT (instead of IntelliJ IDEA’s internal build system). As this option is still experimental, it should be manually enabled via Build / Execution / Deployment / Build Tools / SBT / Use SBT shell for build and import:

SBT Preferences

Another experimental option is running tests via SBT:

SBT Tests

Select Use SBT in the Run Configuration to enable the option. Also select Use UI with SBT to present the results in the standard IDEA test runner:

Test Settings

3. Worksheet

Worksheet architecture now supports REPL mode, which evaluates only newly added expressions without recompiling the existing code:


The Worksheet + REPL combo brings the best of both words: although the evaluation is incremental, you don’t have to wait before typing the next line. Plus you can easily correct previous lines and re-evaluate them, if needed.

As the REPL mode can provide better performance, we plan to use this mode by default in the future. Moreover, we’re considering using the REPL mode for implementation of the standard Scala console.

4. Сode conversion

The Java-to-Scala code conversion is substantially improved. For example, it’s now possible to automatically convert something like this (warning, it contains Java):

Code (before)

…to this:

Code (after)

While previously the conversion worked only for Java code that was copied from IDEA, now it’s possible to convert Java code from text. Here’s an example for you to try:

Simply paste the snippet into a Scala file to see the result. The plugin relies on IntelliJ IDEA’s parser to detect valid Java code for the conversion.

5. Akka

The Ultimate version of the plugin also got a boost – we’ve improved support for Akka. First, we made Find Usages Akka-aware so now it can classify usages of a message class depending on the context:

Find Usages

You can use this to easily find senders or receivers of a particular message in your code.

Because Akka has many “dynamic” parts, some errors are not reported by the Scala compiler. IDE assistance can be of great help in detecting those errors statically (before they are “detected” at runtime).

For example, IntelliJ IDEA can make sure that arguments to a factory method match the actor constructor:


Another thing that can be automated is the generation of factory methods:

Generate Factory Method

The automatically generated code:

Factory Method

Develop with Pleasure!

Posted in New Features, Release report, Uncategorized | 18 Comments

IntelliJ IDEA 2016.3 RC: Scala.Js, Scala.Meta and More

Though we’ve been silent for quite a while recently, it doesn’t mean we’ve not been busy, so today we’re presenting the new features for Scala plugin RC for IntelliJ IDEA 2016.3 that we’ve just created. Continue reading

Posted in EAP, New Features | Tagged , , | 11 Comments

Beyond Code Style

They say “with great power comes great responsibility.” Because of the IntelliJ Scala plugin’s huge user base, most default settings tend to become de-facto standards in the Scala community, so we strive to choose the defaults wisely. Moreover, we believe that sometimes such kind of decisions are worthy of detailed explanations, and subject to approval by the community.

As experience has shown, many introduced novelties are often misunderstood and criticized in the beginning. For example, method signature enforcement was initially touted as some quirk that only keeps getting in the way. But as time went by, those rules and the side-effect thing became “self-evident” in the Scala community, mostly because that’s how all this was intended in the language from the inception. In other cases, like with the deprecation of postfix calls (before SIP-18), we referred to Martin’s tweet as a justification. Because there’s no appropriate Martin’s tweet (yet?) for what we’re introducing this time, we dare validate the step by ourselves.

We’re expanding the notion of “code style” for Scala beyond the typical constituents like spaces, parentheses and braces. For a start, we have introduced a special set of configurable rules of when to add / enforce type annotations (check Settings / Editor / Code style / Scala / Type Annotations). Truth be told, we added those settings about 4 years ago, but only now did we pick up our courage to enable some of those by default (on the other hand, you can’t say we’re rushing it :).

From now on, the type annotation settings will be used in the following functionality:

  • Introduce Variable / Field, Extract Method, Override / Implement Method refactorings,
  • Create Variable / Method from usage,
  • Java-to-Scala code conversion,
  • Reformat Code action with “Add type annotations” enabled,
  • Type Annotation inspection.

In particular, we’re considering enabling the enforcement of type annotations on public methods, and we’re definitely expecting a mixed reaction to that. Why declare some result types explicitly? Well, we believe that it’s one of those places where tools can mend possible abuse of certain liberties in the language design. Here are the reasons:

  • Public methods and properties represent a so-called “public API,” which is a form of abstraction. Forcing API users to investigate the inner workings of public methods (or to guess the result type) is a sure way to break encapsulation and to degrade code quality. Explicit type annotation make public API well-marked and easy to use.
  • Explicit result types can greatly improve code editing performance. Unlike the compiler, an IDE has to re-infer types on each code update. To optimize the workload, IntelliJ IDEA tries its best to cache and preserve as much type information as possible. However, as the result type of a method with omitted type annotation can change even on “external” update (i.e. update outside of the method body), IntelliJ has to re-process the whole content of such a method on almost any change (and the content might often consists of implicits, type-level arithmetic and whatnot). Considering the first point, adding type annotations to public methods makes your code more IDE-friendly (for the same reason, you may also choose to add explicit types to really complex yet non-public methods).
  • Type annotations on public methods increase the speed of incremental compilation by minimizing the amount of recompiled code. Algorithms of incremental compilers (like SBT or IntelliJ) track “public API changes” and dependencies to determine what files need to be recompiled. Thus, if type of some method in a frequently used class is adjusted after code editing (but still lays within some “implied” base type), almost the whole project might often be unnecessary recompiled as a result. In a sense, this argument is a combination of the two previous ones but from the compiler’s standpoint. Official SBT documentation supports this argument by saying that “explicitly annotating return types of a public API is a good practice in general.”

Note: One possible exception to these rules are simple declarations like val answer = 42 where the result type is clearly evident, both for humans and for the compiler. Currently we’re determined to treat this kind of expressions separately.

So, adding explicit types to public methods can make our code cleaner and also speed up editing / compilation. Sounds good, doesn’t it? But what about tons of those “righteous” warnings, aren’t they supposed to be annoying? The good news is that there is a straightforward way to process them all at once:

  1. Go to Settings / Editor / Code Style / Scala / Type Annotations and make sure that Add & Check option is selected for public members.
  2. Invoke Analyze / Inspect Code, select Whole project as a scope and create an inspection profile with only the Type annotation required inspection enabled.
  3. Run the inspection and then choose Apply fix “Add type annotation” to batch-add all the explicit type results.

When SCL-10501 will be implemented, another way to add required type annotations in batch is to invoke Reformat Code with Add type annotations enabled (but this also reformats code for good measure).

Because the functionality is already present in all the Scala plugin builds, you don’t have to wait for it to be enabled by default: you can tweak the code style and try this out right now. Likewise, if you consider the undertaking to be too much of a hassle, just tweak the code style settings as you see fit.

At the next step, we will add many more options to the code style (currently listed as inspections), so that it becomes possible to choose, for example, what form of anonymous function definitions you prefer (person => or or to require eta-expansions to be explicit (like f _), and so on.

We encourage you to try the feature and, as always, we’d love to hear your feedback!


Scala Code Style now tells:

All public methods should have explicit type annotations. Type inference may break encapsulation in these cases, because it depends on internal method and class details. Without an explicit type, a change to the internals of a method or val could alter the public API of the class without warning, potentially breaking client code. Explicit type annotations can also help to improve compile times.


We’ve added fine-grained settings:Type Annotation Settings

Tooltip for the “Type is obvous” checkbox:Type is obvious

Posted in New Features, News and Events | Tagged , , | 24 Comments

How to contribute to IntelliJ Scala plugin

It may well be that you haven’t considered contributing to any open source project, let alone the IntelliJ Scala plugin. However, if you use IntelliJ IDEA to write Scala code, it’s actually a very reasonable thing to do. Here’s how you can benefit from contributing to the plugin code base.

There’s a common misconception about attracting contributors where the process is viewed as “a way to get developers for free.” Nothing could be further from the truth, at least in our case. While the Scala plugin code is open source, there are currently 10 people in the Scala team at JetBrains working on the project full-time. Believe me, we can implement features and fix bugs on our own just fine, and that’s the straightforward way to do that. We’re making additional efforts by creating documentations, publishing tasks, recording videos and doing consulting in order to get to know people and to establish relationship with the Scala community.

Another prejudice that prevents many people from contributing is a notion that “programming an IDE is hard.” I admit that there’s an element of truth in that one, because both IDEA and the Scala plugin code bases are somewhat complex. However, on the one hand, the complexity of different tasks varies greatly, and on the other hand, this provides a great opportunity to learn something new about your tools of the trade. Make no mistake, writing IDE code can be both educational and entertaining!

If you want to contribute, where to start? First I recommend that you watch the video recording of our recent ScalaSphere presentation, Inside IntelliJ Scala plugin. It shows you how to configure the development environment and gradually introduces you to the inner workings of IntelliJ IDEA and the Scala plugin:

The slides (PDF) and the source code are also available.

You can select a task by searching for Up For Grabs tickets in our issue tracker. But don’t feel restricted by that list, as in principle, you are welcome to choose any existing ticket or any task you can imagine.

If you choose to implement one of the 100+ envisioned collection inspections, feel free to check the dedicated article for more info on that endeavor.

Here’s a fuller list of resources you can rely on:

  1. IntelliJ Scala plugin project on Github
    1. Setup instructions in Readme
    2. ScalaSphere branch with examples.
  2. IntelliJ Platform SDK Documentation
    1. Architecture Reference Guide part
    2. Custom Language Support part
  3. Viewing PSI Structure help topic
  4. IntelliJ IDEA project on GitHub (the platform API docs are fairly good)
  5. The Scala Language Specification (PDF)

If you have any questions, you can ask them:

Please don’t hesitate to ask any questions, even “obvious” or, on the contrary, “too hard” and “rhetorical” ones. We actually encourage you to ask questions and to get in touch.

Although the process is a goal in itself, if you happen to implement some feature or fix a bug along the way, just create a pull request or send us a patch, as usual. We also send cookies some small but cool stuff to active contributors, just for the fun of it.

Contribute with pleasure!


The IntelliJ Scala Team

Posted in Uncategorized | Tagged , , , | 17 Comments

Scala Plugin EAP Speeds Up Coding Assistance

Because of its nature, Scala code is really difficult to edit without proper coding assistance. And sometimes said assistance is too slow which makes it not that useful. That’s why we never stop improving our Scala plugin performance. This time we’ve reduced the time needed to provide coding assistance within methods with a defined return type. As a result, code completion and inspections in our latest EAP build now work much faster.



After (see how much faster it is, the animation is 100% real time snapshot):


To give the new EAP build a try, download it from the EAP page, or if you use the EAP plugin upgrade channel, upgrade from the IDE.

Develop with Pleasure!

Posted in EAP, New Features | Tagged , , , | 6 Comments

IntelliJ API to Build Scala Macros Support

Today we’ve released a new Scala plugin EAP build. With this build, we’re happy to introduce an API that extends the IDE coding assistance to custom Scala macros.

A macro is executed at compile-time and modifies the AST of your code: e.g. it can extend the class or its companion object with new methods or other code represented by the AST returned by the macro. Since IntelliJ IDEA’s coding assistance is based on static code analysis, the IDE is not aware of AST changes, and can’t provide appropriate code completion and inspections for the generated code.

Since macros are heavily used in some projects and libraries, we’ve added a special API to the platform that lets build IntelliJ plugins supporting particular macros. Using this API, we earlier added support for Monocle, and now Simulacrum:


Now, everyone can use this API to make their macros more friendly to their favorite IDE. To do that, you have to implement SyntheticMembersInjector, and register it in the plugin.xml file:

The Monocle and Simulacrum implementations will help you understand how to use the API. To help you with setting up a project, we’ve prepared a skeleton. You’re welcome to fork it, and add your implementation.

Once you’ve built a working plugin, it can be installed to the IDE via SettingsPluginsInstall plugin from disk…. If you want to share your plugin with other IntelliJ IDEA users, feel free to upload it to our plugin repository.

We’re eager to hear your feedback on the API. Feel free to share it either here in comments, on our discussion forum, or in the issue tracker.

In case you’d like to have particular macros supported by the Scala plugin, send us pull requests.

Develop with Pleasure!

Posted in EAP, New Features | Tagged , , , , , | 9 Comments

IntelliJ IDEA 15 EAP Adds Postfix Code Completion for Scala

For Java, in addition to the regular completion, IntelliJ IDEA provides so-called Postfix completion: it lets you modify a previously entered expression by adding a “postfix” to it and pressing Tab. This way you can transform your code without unnecessary backward caret jumps.

Many users’ve asked us to support this feature for Scala as well. You asked, we did it:


When a transformation can be applied to several expressions, the IDE will offer you a choice:


Postfix completion suggestions are included in the common completion list, and if you want to see only postfix completion applicable in the context, press Ctrl + J (Cmd + J for OS X):


To see the full list of postfix completion templates, go to Settings → Editor → General → Postfix Completion:


Remember, we welcome your feedback on our discussion forum and your bug reports in the issue tracker.

Develop with Pleasure!

Posted in EAP, New Features | Tagged , , | 3 Comments

Testing Improvements

We’ve recently improved the support for Scala tests in IntelliJ IDEA 15 EAP a bit. Read on to find out more details.

Statically computed expressions in scalaTest/specs2/uTest2 test names are now supported, which means that along with string constants you can use constructions like immutable string variables, concatenation, substring, stripSuffix, stripPrefix, toLowerCase, replace, or trim.


scalaTest/specs2/uTest2 tests and their hierarchy is displayed in the File Structure view when you click Show scala tests.


Don’t forget that your feedback is always welcome in our discussion forum and issue tracker.

Develop with Pleasure!

Posted in EAP, New Features | Tagged , , | 7 Comments