JakubMisek phptools I see, it makes sense. As a result, we wouldn't be providing code completion within the' vendor' folder though.
JakubMisek phptools I guess we have to scan all the .php files. The 2nd vendor might be needed in order to analyse the 1st vendor right?
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)
