noahfrederick / vim-composer

Vim support for Composer PHP projects

Sorry, I'm no longer hosting code on GitHub.¹

You can find up-to-date copies of all code repositories at codeberg.org/noahfrederick.

If you use a Vim/Neovim plug-in managed via Git, you will need to update the name/URL from, e.g., noahfrederick/vim-plugin-name to https://codeberg.org/noahfrederick/vim-plugin-name to continue receiving updates.

Footnotes

1. Copilot (a commercial LLM trained on source-available code hosted on GitHub without the authors' knowledge or consent) represents an unacceptable incursion by Microsoft, an attempt to lay claim to undefended territory in their quest to capture surplus value.

   There are also other reasons to avoid using GitHub, such as the requirement to run non-free JavaScript to use certain features of the website, and Microsoft's unscrupulous business contracts. ↩

vim-composer's Issues

Cache is not scoped to project

To reproduce:

• :e project-a/composer.json
• :PP composer#project().json()
• :e project-b/composer.json
• :PP composer#project().json() gives same result

Support <Plug>(composer-find) from dependencies

When you jump to a class belonging to a dependency of the current project, b:composer_root changes to the root of that package.

Example: jump from ~/code/foo/index.php to ~/code/foo/vendor/org/package/Bar.php, b:composer_root changes to ~/code/foo/vendor/org/package.

Then, when you want to jump to another class that is referenced in Bar.php, it won't work because the installed dependency (org/package) doesn't have a vendor folder. It uses the vendor folder from the dependent project (~/code/foo).

I can think of two solutions:

1. When figuring out b:composer_root, check if both a composer.json and vendor/autoload.php exist.
   • If only a composer.json exists, look for a parent folder containing both composer.json and vendor/autoload.php.
     • If only a composer.json exists in that directory too, just use the originally found root.
     • If both a composer.json and vendor/autoload.php were found, use that directory as the root.
2. Let <Plug>(composer-find) look for a vendor/autoload.php, regardless of b:composer_root. This would be preferred if b:composer_root should always be the lowermost directory with a composer.json.

I would prefer the first one, unless there's a reason to set b:composer_root to the root of the dependency?

<Plug>(composer-find) doesn't work in use statement with alias

When the cursor is on Foo\Bar in use Foo\Bar as Baz, it tries to expand the name using the current namespace because of the lack of leading \. Note that it works without the as part because we can resolve the name by looking for matching use statement (which only matches on the alias, if present) before resorting to expanding the name using the current file's namespace.

CreateProcess failed on Windows 10

Windows composer package is coming with the composer.bat starting script hence :terminal composer does not work, but :terminal composer.bat does.

Idea: find classes from composer class map

This plugin could use class map built with composer dump-autoload -o to look for class name under cursor and use it for navigation and inserting of use statements.
As far as I can see the plugin can't do it now.

Class map is written into file vendor/composer/autoload_static.php in $classMap property and holds list of all the classes found in the project like this:

public static $classMap = array (
    'Behat\\Gherkin\\Cache\\CacheInterface' => __DIR__ . '/..' . '/behat/gherkin/src/Behat/Gherkin/Cache/CacheInterface.php',
    'Behat\\Gherkin\\Cache\\FileCache' => __DIR__ . '/..' . '/behat/gherkin/src/Behat/Gherkin/Cache/FileCache.php',                                                                              
    ...

There could be classes that are available in several namespaces then plugin could show menu to select which class to proceed with.

Functionality like this is really missing now. There is no working solution for the moment.
Ctags way is not good because tags file is huge (hundreds of megabytes) for big (not huge) projects.
PHP language server is just not stable enough for the moment.
So this could be a killing feature :)