Mago's future

[Bleksak]

Hi, after a long time, this is a project I am a really huge fan of. I would like to ask about its future and possibly share some ideas of my own.

You've already tried making an LSP, which is great. I think PHP is in a desperate need of a proper LSP and this project could really be it. It would be great if it could implement some of the most used php libraries and frameworks as they use a lot of PHP internal magic which is why LSPs suck currently. Some of these are: Symfony, Laravel, Doctrine, Wordpress, PHPUnit, Pest.

I'm sure we can agree, that Rust brings a lot of safety. And not only memory safety, but also prevents logical mistakes. It's also (in my opinion) the best language to do language parsing. Performance is a great side effect of Rust, and I want to thank you for making performance one of the goals of this project.
Having said that - if we take a look at Javascript side - they have multiple runtimes - bun, node, deno and maybe more that I don't know of. PHP has only had one. I'm not sure how hard would that be to implement, but I think this project could become the second PHP runtime (and it could be faster too).

Composer is a great tool, and it works perfectly. However, I feel that Rust has done a great job of providing all tooling with its toolchain (compiler, package manager, bundler and an LSP in one package). Maybe we could tackle on having a second package manager for PHP too?

What I'm trying to propose is unified do-all PHP solution from which the PHP community would greatly benefit.

Thank you for reading, and let me know what do you think.
And please let me know, what's planned for mago right now and if I could help somehow as I'm greatly interested in this tool.

[Vanecek0]

Great ideas! I'll support them for sure :)

[azjezz]

Thank you so much for the incredibly thoughtful and encouraging post! It's fantastic to hear from fans of the project, and I really appreciate you taking the time to share your vision. You've touched on many of the core motivations behind Mago.

Let me address your ideas and then share the current roadmap.

---

The Grand Vision: Runtime and Package Manager

You've perfectly captured the "unified do-all" spirit that inspired Mago. While I share that ambition, a new PHP runtime and a Composer replacement are two areas I've decided not to tackle for a few key reasons.

On a New PHP Runtime

This is an incredibly difficult task. The PHP engine is filled with complex behaviors and edge cases that have evolved over decades. My primary concern is compatibility.

• The HHVM Example: If a team with Facebook's resources couldn't achieve 100% compatibility with Zend, it's an almost impossible task for a solo developer.
• The Extension API: A new runtime would need a C extension API compatible with the thousands of existing PECL extensions. Without it, the runtime would be a non-starter for most real-world projects.

Releasing a new engine that isn't fully compatible would do more harm than good to the ecosystem. The time and effort required are simply immense.

On a Composer Replacement

This is another area I don't plan to touch, mainly because Composer is a great tool that works very well.

• I/O-Bound Performance: While a Rust-based dependency resolver would be faster, the bulk of the time in composer install is spent downloading files (I/O), not resolving dependencies. A Rust version would still be limited by network speed and wouldn't provide a game-changing performance benefit.
• The Plugin Ecosystem: Composer has a rich plugin API that many projects rely on. For a Rust implementation to be a true replacement, it would need to embed a PHP VM to invoke these plugins, which is a massive undertaking.

The Official Roadmap (What's Coming Next)

While those areas are off the table, we have very exciting plans that align with your other ideas! Here are the definite, planned features for the future:

1. Language Server (LSP): This is the #1 priority. You are absolutely right that PHP is in desperate need of a proper, high-performance LSP.

2. Advanced Migration Tool: This will be a powerful tool to automatically migrate projects between different versions, both forwards and backwards. This wouldn't just be for PHP versions, but also for major framework and library versions (e.g., migrating a Symfony 5.4 project to 6.4). It will use careful static analysis to handle breaking changes automatically.

Future Possibilities (The Wishlist)

These are features I'd love to implement once the core roadmap is further along:

• PHP Version Manager: mago php:install 8.4, mago php:switch 8.2. A cross-platform, native tool to manage your PHP installations seamlessly.
• PHP Extension Manager: A tool to handle downloading, enabling, and disabling PHP extensions for you.

How You Can Help

I'm so glad you're interested in helping! The best way to contribute right now is:

• Testing and Issue Reporting: Use Mago on your projects and report any bugs or unexpected behavior. Detailed issue reports are incredibly valuable.
• Contributing to the Linter: The linter is a great place to start contributing. Adding new rules is a very straightforward process, and we welcome ideas for rules from other tools.
• Documentation: Helping to improve the documentation is always a huge help.

[ruudk]

Regarding PHP Extension Manager, this is already being handled by the PHP organization: PIE 🥧

[azjezz]

It would kinda be needed anyways if we are going to manage PHP versions, as usually people want to add/remove extensions after installing a new version.

[trymeouteh]

I am all for a PHP version manager and PHP extension manager.

I would not be against a PHP package manager alternative to composer either.

I am not a fan of PHP tools written in PHP, with the exception of testing tools like PHPUnit.

I would like to see a PHP rewrite from C\C+ into a memory safe language such as Go or Rust, but this should be done by PHP devs themselves as this rewrite will have breaking changes to older PHP code due to the migration.

[chx]

[Bleksak]

We will support adding custom rules in the future.

[azjezz]

It is viable. Mago's migration will focus mainly on two things:

1. upgrading PHP versions, we will be implementing all rulles needed for to upgrade from a specific PHP version to another. this is not an issue.
2. upgrading Framework versions, specifaclly, we will focus on Symfony, Laravel, Doctrine, PHPUnit, and Tempest. again, we will be the ones implementing the rules to cover all changes that happened between a specific version and another.

[azjezz]

I am curious how do you see this working across operating systems and various SAPIs.

I don't understand what you mean by this? We would simply have an installer implementation for every OS we support i.e Linux, MacOS, Windows, and FreeBSD. Mago will maintain a global config directory that will contain all PHP installations, and switches between them.