phptools JakubMisek Composer is a flat single layer dependency manager, so all the required files are in the first vendor. As such, there is no need to scan the 2nd vendor. But I would suggest this to be made as a generic configuration rather than 1 specific to composer, perhaps exclude scanning vendor/**/vendor?
JakubMisek phptools I see. But the 2nd vendor contains declarations needed by a package in the 1st vendor right?
phptools JakubMisek 2nd vendor contains declarations needed by a package in the 1st vendor right? Yes, but because composer operates on only 1 level, those declarations are already found in the 1st vendor. As such there is no need to scan the 2nd vendor Let's say the project is A, and it needs B. B needs C When we run composer require B, this command will also add C into the project, thus 1st vendor will already know about C There is no need to scan B's vendor to know about C Makes sense?
phptools In case you wonder why the 2nd vendor is exists, that is because the package B looks inside its child folders for the packages it needs, it will not look towards its parent(s)
JakubMisek phptools For that purpose, I thought the composer had an API providing the list of installed packages, their paths, and package dependencies.
JakubMisek pre-release 1.37.13695 ignores the nested /vendor/, please let me know how it works for you)
JakubMisek Version 1.38 avoids allocating and indexing /vendor/ folder if not necessary. There is a new caching mechanism and several improvements. Please update and let us know how it works. Thanks!
phptools JakubMisek My v1.39.13943 language server is taking very long to do its job again. Any idea?
JakubMisek phptools It should not be more than a few seconds. Please try the pre-release 1.39.13983 which handles symlinks in /vendor/ folder - it seems like it's your case.
phptools Not sure what I did, but it seems better now. Here's what happened: It was slow, I did a reboot, still slow, so I sent the screenshot above I did add this "files.exclude": { "inherit": true, "**/vendor/**/vendor/**": true // had no effect whether enabled or not }, //excludes fies & folders for watcher service "files.watcherExclude": { "**/.git/objects/**": true, "**/.git/subtree-cache/**": true, "**/node_modules/**": true, "**/env/**": true, "**/venv/**": true }, "search.exclude": { "**/node_modules": true, "**/bower_components": true, "**/env": true, "**/venv": true },
phptools JakubMisek Go to Definition breaks when I add this, feels like a bug to me "files.exclude": { "**/vendor/**/vendor/**": true }, Is there a way to make the extension stay on a certain version so that I can stay in a known state? Perhaps using a configuration setting?
JakubMisek phptools 1/ Go To Definition will ignore definitions in the /vendor/**/vendor workspace folders in this case. 2/ You can always choose a specific version in VSCode / Extensions panel /
phptools Hi, this remains to be a problem to the extent that I have to constantly find and delete my nested vendor folders. Language server must SCAN: vendor/** Language server must NOT SCAN: vendor/**/vendor Possible to configure the above?
JakubMisek phptools thank you for reminding me. Currently, we index everything in /vendor/**; I'm aware it's incorrect, and we're working on it. I think we should (by default) ignore vendor/**/vendor/ (unless you explicitly open that file in the editor)
phptools I'm thinking, the logic can be simplified to If PHPTools finds vendor folders that are exactly 2 segments apart, then skip it e.g. **/vendor/1/2/vendor It should work because this is the way nested vendor by composer would look like. Also, there are some packages out there that chose to name some of their folders as vendor 🤦♂🤦♂🤦♂ Hide this behind a checkbox (Experimental) Skip nested vendor folders. If it solves the problem, then we can work on something more "proper"
JakubMisek @phptools finally after long time files.exclude and search.exclude patterns will behave as expected The next update will respect both settings and should behave correctly. ( https://github.com/DEVSENSE/phptools-docs/issues/780#issuecomment-2781399853 ) If there will be inconsistencies, please report :)
