PHP: "vendor" folder should not be ignored by default

[pscheit]

Current Behavior

In intelephense.py, vendor directories are hardcoded to be ignored:

def is_ignored_dirname(self, dirname: str) -> bool:
    # For PHP projects, we should ignore:
    # - vendor: third-party dependencies managed by Composer
    # - node_modules: if the project has JavaScript components
    # - cache: commonly used for caching
    return super().is_ignored_dirname(dirname) or dirname in ["node_modules", "vendor", "cache"]

The Problem

This creates a contradiction with Serena's core value proposition:

Serena's instructions say: "Don't read entire files - use symbolic tools like find_symbol to explore code efficiently"

But in practice: When working with third-party libraries, I'm forced to read entire vendor files because find_symbol doesn't work on them.

Concrete example:

• I'm using brick/date-time and need to understand how ZonedDateTime::parse() works
• find_symbol with depth: 1 returns empty for vendor classes
• I have to fall back to reading the entire ZonedDateTime.php file (700+ lines)
• This defeats Serena's purpose of efficient code exploration

Why This Matters for PHP Projects

1. Third-party library exploration is crucial - Understanding external APIs is often MORE important than understanding your own code (which you wrote)

2. Current workarounds don't work:

   • Setting ignore_all_files_in_gitignore: false in .serena/project.yml has no effect
   • The hardcoded exclusion overrides configuration

3. The LLM gets stuck: Claude Code receives instructions to "use symbolic tools, don't read files" but then can't use those tools on vendor code, creating confusion

Proposed Solution

Make this configurable via ls_specific_settings in .serena/project.yml:

ls_specific_settings:
  php:
    indexVendorDirectory: true  # default: false

Or alternatively as a project-level setting:

index_vendor_directories: true  # default: false

Performance Tradeoff

Yes, indexing would be slower with vendor included. However:

• PHP developers are accustomed to slow indexing (PHPStorm: ~10 minutes)
• This should be opt-in for teams that need it
• The performance cost is worth it for proper third-party API exploration
• Indexing happens once; exploration happens continuously

Testing Notes

I've locally patched line 39 to remove "vendor" from the exclusion list and can confirm:

• Vendor indexing works correctly
• find_symbol successfully returns methods from vendor classes
• No issues with Intelephense handling vendor files

Would be happy to test any proposed implementation!

[MischaPanch]

Hi. Yes, making it configurable through LS specific settings is a good idea. I am not sure about the default, but in principle I wouldn't mind True. @opcode81 wdyt?

Would you want to make a PR for that @pscheit ? Btw, maybe you're interested in taking a look at #713 - no idea whether it offers benefits over intelephense (I rarely write PHP these days)

[opcode81]

I am not sure this even needs to be configurable. Unless Intelephense will crash or really take excessively long in the presence of too many vendor files, it is literally always preferable to have dependencies indexed.
The original implementor added the exclusion, but it might have been just a "reflex".

@pscheit, from your PHP development experience, is there any reason to exclude vendor files? Do you have large projects for which indexing them is indeed problematic?

Of course, there are also cases where the vendor folder will be git-ignored, which will cause them to be ignored even if we change the hard-coded condition in the LS.

[shortontech]

@opcode81 I think the expectation for most PHP devs is that the vendor folder would be indexed. I think I understand the reflex to exclude the vendor and node_modules folder - the open file limit(on Linux) can be reached quickly with intelephense scanning all of the vendor files, or the usage of phpstan combined with intelephense and VS Code will reach that limit quickly on a chunky codebase, and that's likely where this exclusion came from.

I suspect we Linux users are in a minority, and it's better to have us deal with our open file limit issues ourselves -- it will be obvious to us when our tools start giving us an error saying EMFILE: too many open files.