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
doc: update #594
base: 1.x
Are you sure you want to change the base?
doc: update #594
Conversation
|
||
You can override this configuration by using the ``--namespace`` option. | ||
|
||
|
||
.. note:: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is no longer applicable - @nikophil, can you confirm?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually this is still true. If you have a @method
which basically is a lie, you'll need the @phpstan-method
annotation.
But I've just tested with foundry 2 + phpstorm 2023.3, and autocompletion comes out of the box, even with PersistentProxyObjectFactory
I think this is because phpstorm really improved how it handles generics + we now return @return T&Proxy<T>
which is easier to understand than the old Proxy<T>
which is a @mixin
of a template, which phpstorm notoriously does not handle very well.
So... maybe we should remove all the @method
even in doc? On the other hand, not anybody uses phpstorm. So we can document both @method
and @phpstan-method
in a .. note::
: "if autocomplete does not work out of the box, you can still add @method
, but be sure to add @phpstan-method
as well..."?
I think we should also remove these phpdoc from the make:factory
command, and make it optional with an option --add-phpdocs
. WDYT?
# Whether to auto-refresh proxies by default (https://symfony.com/bundles/ZenstruckFoundryBundle/current/index.html#auto-refresh) | ||
auto_refresh_proxies: null |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we should document this, since it has no effect
*/ | ||
final class PostFactory extends ModelFactory | ||
final class PostFactory extends PersistentProxyObjectFactory |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
don't we miss an introduction which explains the difference between PersistentProxyObjectFactory
, PersistentObjectFactory
and ObjectFactory
? with pros and cons for each?
maybe also a word on ArrayFactory
?
|
||
You can override this configuration by using the ``--namespace`` option. | ||
|
||
|
||
.. note:: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually this is still true. If you have a @method
which basically is a lie, you'll need the @phpstan-method
annotation.
But I've just tested with foundry 2 + phpstorm 2023.3, and autocompletion comes out of the box, even with PersistentProxyObjectFactory
I think this is because phpstorm really improved how it handles generics + we now return @return T&Proxy<T>
which is easier to understand than the old Proxy<T>
which is a @mixin
of a template, which phpstorm notoriously does not handle very well.
So... maybe we should remove all the @method
even in doc? On the other hand, not anybody uses phpstorm. So we can document both @method
and @phpstan-method
in a .. note::
: "if autocomplete does not work out of the box, you can still add @method
, but be sure to add @phpstan-method
as well..."?
I think we should also remove these phpdoc from the make:factory
command, and make it optional with an option --add-phpdocs
. WDYT?
something else: WDYT about documenting this little, but still useful, behavior (the stuff with |
make_story: | ||
default_namespace: 'App\\MyStories' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shouldn't we keep this? based on #516 (comment) I think we should (and upmerge the related PR)
No description provided.