-
Notifications
You must be signed in to change notification settings - Fork 664
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support Doctrine via stubbed templates #849
Comments
Also |
That would be immensely useful, especially being able to partially stub things. We have some stubs for Doctrine Collections and a couple of other libraries, it would be nice to have a way to distribute them. |
I've updated the stubs above to one that I've got working. Unfortunately I don't have a codebase that uses Doctrine ORM to test against - any suggestions? Also @weirdan if you could post those stubs to a new repo, you could require that repo via composer and include a ref to the |
I think the best thing is to require each extension repo have a |
For me, relying on the file paths is a problematic part (due to the particular setup we use, but also in general), so I'd like to relegate as much of the file structure heavy-lifting to composer. Which means I'd like to see plugins addressed by namespace/classname, not by file path. If you're open to this idea I can draft up a kind of proposal the following week. |
@weirdan absolutely. The only thing I was thinking is that it I'd want to provide an easy way to disable extensions/plugins, which is cumbersome if you have to do it via Composer. I was thinking something like <extensions>
<directory name="vendor/muglug/psalm-doctrine-ext" />
</extensions> You may also |
Sure, it's on my todo.
That's file path, and that's what I'd like to avoid. The approach I'm working on wouldn't require any file paths (but PoC would be a bit tied to composer infrastructure, with an option to unbind it later).
It's likely to be dev-required (rather than required), and composer does not install dev-dependencies of your dependencies. Still, it's a valid point, and would be addressed. |
Brilliant! If you can address that, then I'm happy relying on composer. I was thinking that each package would add a registration script into |
@weirdan is this done in your own plugin? |
Mostly. I don't have EntityManager there, but considered adding that (and renaming to psalm-doctrine). I plan to get back to it the week after next, when I'm back in the office. |
Thanks! |
…s this didn't work correctly and lead to errors not being reported at all in many cases (since the error was reported for the stubs file and therefore suppressed) With the previous commit "Fix for classes what vimeo#8503 fixed for functions", the stubs of classes where the actual file is in the analyzed files are ignored completely.
…s this didn't work correctly and lead to errors not being reported at all in many cases (since the error was reported for the stubs file and therefore suppressed) With the previous commit "Fix for classes what vimeo#8503 fixed for functions", the stubs of classes where the actual file is in the analyzed files are ignored completely.
…s this didn't work correctly and lead to errors not being reported at all in many cases (since the error was reported for the stubs file and therefore suppressed) With the previous commit "Fix for classes what vimeo#8503 fixed for functions", the stubs of classes where the actual file is in the analyzed files are ignored completely.
…s this didn't work correctly and lead to errors not being reported at all in many cases (since the error was reported for the stubs file and therefore suppressed) With the previous commit "Fix for classes what vimeo#8503 fixed for functions", the stubs of classes where the actual file is in the analyzed files are ignored completely.
…s this didn't work correctly and lead to errors not being reported at all in many cases (since the error was reported for the stubs file and therefore suppressed) With the previous commit "Fix for classes what vimeo#8503 fixed for functions", the stubs of classes where the actual file is in the analyzed files are ignored completely.
…s this didn't work correctly and lead to errors not being reported at all in many cases (since the error was reported for the stubs file and therefore suppressed) With the previous commit "Fix for classes what vimeo#8503 fixed for functions", the stubs of classes where the actual file is in the analyzed files are ignored completely.
…s this didn't work correctly and lead to errors not being reported at all in many cases (since the error was reported for the stubs file and therefore suppressed) With the previous commit "Fix for classes what vimeo#8503 fixed for functions", the stubs of classes where the actual file is in the analyzed files are ignored completely.
…s this didn't work correctly and lead to errors not being reported at all in many cases (since the error was reported for the stubs file and therefore suppressed) With the previous commit "Fix for classes what vimeo#8503 fixed for functions", the stubs of classes where the actual file is in the analyzed files are ignored completely.
Partial stubs like this should be importable into a given project by including the package via composer.
The text was updated successfully, but these errors were encountered: