MPS 2024.1 Is Out!
In this release, you’ll find a new asynchronous implementation of the Logical View tool window, substantial improvements to Kotlin support for different platforms, and a noticeably faster test run time. You can also look forward to conditional forks in generator plans, deprecation of project paths in TestInfo, improvements to the new UI, and numerous platform updates.
Before we go over the specific features, we have two quick announcements for you:
The time has come for a new UI in MPS
MPS is moving towards a new UI, which brings a more modern look and increases user productivity. The new UI has been fully enabled in MPS 2023.3. In 2024.1 it is set as the default for new MPS users, and in 2024.2 we plan to abandon the old UI altogether. We may keep it around as a separate plugin, but not for long.
We encourage all users to switch to the new UI by going to Settings | Appearance & Behavior | New UI.
Additionally, if you’re building standalone IDEs, it’s time to configure your build scripts to generate IDEs with the new UI enabled.
There are currently two VM options that have an effect on which UI version is offered to the users of your IDE. You can configure these options in your build scripts:
- -Dide.experimental.ui – This option switches the new UI on or off for new users of your IDE. It is set to false for standalone IDE build scripts in 2023.3 and 2024.1.
- -Dexperimental.ui.used.once – When this is present, it will disable an automatic in-tool promotion that advertises the new UI to the users. This option is enabled by default for standalone IDE build scripts in 2023.3 and 2024.1.
The MPS IDEA plugin has been discontinued
With the user base for the IDEA plugin decreasing, we decided to discontinue the plugin and to invest our efforts into features that bring more value to customers and help make their work more enjoyable. The plugin is no longer available for download.
The new features
Having covered these two important announcements, now it’s time to check out the most exciting new features we’ve prepared for you in this release.
Enhanced platform support for Kotlin
The Kotlin support in MPS was initially designed to support only common code. However, the only possible use case in MPS was compilation to the JVM, and the distinction between common code and JVM code was unclear.
In this release, we’re introducing platform source set configuration for Kotlin nodes. This allows you to identify which target platforms a piece of code supports and hide declarations from incompatible code.
Improved Kotlin readability without the Coderules type system
Kotlin code in MPS used to raise a lot of typesystem and scope errors when the Kotlin Typesystem plugin, based on CodeRules, was not available. In order to improve readability and testability, these checks and errors are now muted when the Coderules-based typesystem plugin is not available.
In such cases, all scopes in Kotlin languages are replaced with a default scope including all nodes of compatible concepts. This removes any false-positive errors, as all valid nodes are in the scope.
The guidelines for dealing with Kotlin code remain the same as before:
- Writing and checking Kotlin code should be done with Coderules enabled and the Kotlin type system plugin installed.
- Reading Kotlin and generating it can be safely performed without them.
Reimplementation of the Logical View pane
The Logical View pane is now based on an asynchronous architecture, which helps keep the UI responsive and contributes to the overall performance of the IDE. The new implementation also allows for easier extensions and modifications. For more details, refer to our article in the knowledge base entitled ProjectPane implementation on top of ProjectViewTree.
This new implementation has resulted in a few notable changes:
- Error and warning indicators are no longer available.
- Both errors and warnings found in the hierarchy are underlined in red.
- The Show Descriptor Models option affects all descriptor models.
- Some drag-and-drop operations work differently.
- The settings in the Logical View pane have been reorganized slightly.
Placeholder cells
We’ve introduced a new style into BaseLanguage that allows constant cells to serve as placeholders if there’s a missing value (a child node or a reference). For example, when no constructor is present in a class, a <no default constructor> placeholder cell can be displayed instead. The style causes constant cells to exhibit the behavior you would expect from such placeholder cells. The cursor can only be placed on the first position, and it is not possible to edit the value. Only modifications provided by attached transformation menus are permitted.
Enable conditional fork in generation plans
A small experimental new feature enables you to add a fork for a generation plan without actually modifying the original plan that is being forked. A generation plan can be marked as a fork of another generation plan. The marked plan will be treated as if it were referred to explicitly with the standard fork statement inserted at the very beginning of the forked generation plan.
Additionally, when defining a fork, you can use a string modifier that will serve as a trigger. The fork will only happen if the model being generated is owned by a module that has a generation target facet with a facet ID matching the string trigger.
JUnit5 xml report in MPS
JUnit tests in MPS can now generate test reports not only in the vintage and jupiter formats, but also in the Open Test report format. A new option is available in the build language’s test options to control whether the Open Test report is included in the generated reports. If the option is set to true, report files named junit-platform-events*-$BUILD_NAME$.xml are created in the project directory.
If the option is set to false, the legacy reports for vintage and jupiter engines are created.
The project paths in TestInfo are no longer needed
TestInfo declarations are no longer required for tests that need an MPS project to be open. This applies to all approaches to executing the JUnit tests:
- If the test is run from the IDE, either in-process or out-of-process, the project currently open will be used.
- If the test is run with the <launchtests> task, the project path can be specified as an additional project path option of the task. If left unspecified, ${basedir} is used, which corresponds to the home directory of the current project.
- For special cases where neither of the above approaches can be used, you can specify the project location via the -Dmps.test.project.path system property.
Existing TestInfo declarations are still supported and can be kept.
More new features…
Check out the What’s New page to learn all about the new features we’ve added for you.
You can find a full list of fixed issues here.
Your JetBrains MPS team
Subscribe to MPS Blog updates
