What’s Next in PhpStorm: The 2023.1 Public Roadmap
In the first release of 2023, we aim to improve performance and bring faster indexing, add 3v4l integration, improve support for generics, as well as PHPStan and Psalm tags, add support for multi-composer and multi-vendor projects, and more.
Before the release of 2022.3, we published our first-ever public roadmap and announced what we would be working on. The feedback on the blog, on Reddit, and elsewhere has been very helpful – thank you very much.
We decided to continue this tradition and regularly publish our plans. We want PhpStorm to be the best tool for you, so we’ll share our intentions and ideas, and of course we are open to any criticism and suggestions.
The plan is subject to change, and we cannot guarantee that all of the items below will make it into version 2023.1.
What’s coming in PhpStorm 2023.1
Better performance for PHP code
We’re always working on improving performance. But in this release, we’ll put more effort into making PhpStorm significantly faster.
There are many things we’ll try to improve. Here are the main initiatives.
Better IDE responsiveness
To make the experience of editing and interacting with code lightweight and smooth, we’ll fix known freezes, enhance menu responsiveness, and move some additional computations to background threads.
Faster code insights
We’ll aim to speed up code highlighting, indexing, and resource-intensive inspections.
More actions available during indexing
For you to be able to get the most out of PhpStorm, it first needs to index your files. Although we’re working on making indexing faster, we also have plans to allow more features to run while indexing is still in progress.
In this release we’ll focus on making completion available in more places during indexing, allowing you to execute actions and even perform code navigation, such as Go to class, on partial indexes.
Downloadable shared indexes
Unlike regular indexes, which are built locally in your PhpStorm, shared indexes are generated once and are later reused on another computer whenever they are needed.
For example, symfony/console is one of the most used PHP packages in the world. Why should everyone need to compute its index over and over again if we can just index it once and share it? This is what shared indexes are about.
We are committed to trying to implement shared indexes for PHP packages in this release. However, this is an experiment, and while it may bring some advantages in certain scenarios, in others it may not bring any improvement at all. Some reasons for that include the following:
- We can index only the most popular packages and their most popular versions.
- On some setups, local indexing may be faster than the download speed for shared indexes.
By the way, you can generate your own shared indexes for your private projects. Learn more about how to do that in the documentation.
Here is, for instance, a prebuilt shared index for Shopware by Shyim: https://github.com/shopwareLabs/shopware-shared-project-cache-generator
With these improvements, we hope that indexing will be less of an interruption to your working flow and you won’t have a “compilation step”. :-)
Run PHP snippets on 3v4l.org right in the IDE
In the upcoming PhpStorm release, you’ll be able to test PHP code via the popular 3v4l.org tool.
As it runs on all PHP versions, it’s very convenient for quickly testing and comparing the behavior of certain code.
If you find 3v4l.org useful, consider supporting its author with a donation https://3v4l.org/sponsor.
Automatic configuration of local setup
Currently, when you open a project for the first time, you may need to configure a few things manually. For example, you may have to specify the PHP interpreter or set up quality tools and other third-party integrations.
We’d like to automate as much of this configuration as possible for you. Ideally, you would just need to open a project and run `composer install` from the terminal or PhpStorm, and the rest would be configured for you.
What do you currently find most annoying about configuring a project? Let us know, as we’d like to address it.
Run quality tools on actual project files
Historically for technical reasons, PhpStorm performed on-the-fly analysis with third-party tools, such as CodeSniffer, on temporary copies of real files. This was a safer and more reliable way to implement it, but the downside is that some features didn’t work as expected, for example the ability to exclude files by path.
In the upcoming release, we will attempt to run tools on real files, which would eliminate the need for workarounds.
Clickable paths and class references for var_dump() / dd() output in the terminal
We want to improve the debugging experience for users who prefer the ‘dump and die’ approach. As a first step, we’ve already made active file paths and class references. Clicking on them will open the corresponding file in the editor.
We plan to add more augmented features for the terminal. What would you like to see?
Generics support improvements
Support for generics is traditionally one of the most desirable features in PHP. Regardless of whether this feature is implemented natively in PHP or not, we want users to be able to fully benefit from generics in PhpStorm.
In this release, we will improve inspections for generics and cover the remaining edge cases. Here are some of the top-voted issues that we plan to address:
- WI-65460 Infer the “@template T of Type” in the generic class itself.
- WI-62769 Generics: Support wrapping T into T[].
- WI-64022 Support @mixin with template.
- WI-69638 Support Generics Type in @mixin.
- WI-63498 Generics: Cannot combine extends with template.
- WI-63845 Generic autocomplete does not work with class properties.
- WI-63722 Generics doesn’t preserve `static` type.
Support for all PHPStan and Psalm tags
We also want to improve support for PHPStan and Psalm tags. We intend to add parsing for all existing tags, type inference, and some special highlighting in advance.
For example, currently PhpStorm does not parse the following tags: @param-out, @assert, @assert-if-false, @assert-if-true, and about 15 others. That will be fixed in the next release.
We also plan to add more support in the IDE for some tags: @api, @immutable, @mutation-free, @no-named-arguments, and @readonly.
Support for multi-composer and multi-vendor projects
Currently, PhpStorm treats any open project as a single space. However, users often have several independent applications in the same project, all with their own `composer.json` dependencies.
We want to implement support for these kinds of projects with multiple `composer.json` files and vendor directories. This will allow you to set different source roots, test directories, and even different language levels. So one of your services can be on PHP 7.4 while another is on the latest PHP 8.2 – with both in the same project open in one PhpStorm window.
Adding DFA (data flow analysis) debugger
Users who prefer Xdebug for debugging PHP applications will soon have even more advanced support.
The DFA debugger will allow you to see the branches of code that will never be executed. But the trick is that you will not need to use Step-into to see that. The conditions will have computed values ahead of time.
Let’s see it in action. Consider this code:
You can see that PhpStorm knows the result of the conditions before the code is executed, so you can get a sense of the situation in the code without going further.
We will add inlay values of precomputed conditions. Additionally, we may gray out any branches that won’t be executed, as on the video above. What are your thoughts on graying out? Is it confusing with unused code?
That’s pretty much it. Once more, we can’t promise that all of these upgrades will be part of 2023.1, but we’ll try to make it happen. Keep an eye out for the launch of the Early Access Program in 2023.1.
Please share your feedback with us – send us a tweet at @phpstorm, leave a comment under the post, or open a ticket by selecting Help | Submit a Bug Report in PhpStorm’s main menu.
Subscribe to PhpStorm Blog updates
