Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[RFC] Exceptions that suggest your missing package #25256

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

Closed
weaverryan opened this issue Dec 1, 2017 · 7 comments
Closed

[RFC] Exceptions that suggest your missing package #25256

weaverryan opened this issue Dec 1, 2017 · 7 comments
Labels
DX DX = Developer eXperience (anything that improves the experience of using Symfony)

Comments

@weaverryan
Copy link
Member

Q A
Bug report? no
Feature request? yes
BC Break report? no
RFC? yes
Symfony version 4.1.0

The negative of Flex is that if you try to use a feature that's not installed, you'll get an error. Recently, we updated the exception messages in ControllerTrait to suggest the package that the user is missing when necessary.

But there are so many other cases. For example, if you use {{ asset() }} in Twig without the Asset component:

screen shot 2017-12-01 at 1 28 32 pm

Idea: Add new dev-only behavior that somehow enhances this error page to add a:

To fix this, run "composer require asset"

We would maintain a list of error patterns/strings and what package is needed somewhere. This could even be stored in Flex itself, so that it could be updated easily and more often.

@xabbuh xabbuh added the DX DX = Developer eXperience (anything that improves the experience of using Symfony) label Dec 1, 2017
@nicolas-grekas
Copy link
Member

in the Debug component?
be a more local patch would be easier to maintain.
e.g. in this case, is there anyway to hook into the failure, should we create one?

@fabpot
Copy link
Member

fabpot commented Dec 2, 2017

ahah, this is on my todo-list. Not sure where that would be best though.

@nicolas-grekas
Copy link
Member

Locally to every failure IMHO. There need to be an inventory somewhere. And I fear maintaining that in a separate location will be unmaintainable.

We could also keep the messages, but add a method on exception classes like "setMissingComponent", and use that in some generic renderer.
Or we could just put that in the messages.

@sroze
Copy link
Contributor

sroze commented Dec 6, 2017

I don't think that putting this in the messages is sustainable. @weaverryan's example is good to show that it won't be possible to add something about the component to be installed with such exception.

The thing that is installed with every Symfony skeleton application is the FrameworkBundle and I believe it's the right place to add such handling. We could have some extensions in it that would catch Twig's functions, missing classes and services and suggest components, based on the list of provided twig functions, classes and services for a given list of components.

@weaverryan
Copy link
Member Author

Yea, I agree with @sroze: I'm not sure this is really possible (the missing Twig function is a good example) by calling a setMissingComponent method everywhere necessary. But yea, maintaining this list and causing extra traffic on the main repo is legitimate.

One option would be to create a new repository that contains just this data and add that as a dependency to frameworkbundle. That would simply be a way to push the traffic to a different repository... if it's worth it.

@fabpot fabpot closed this as completed Dec 30, 2017
fabpot added a commit that referenced this issue Dec 30, 2017
…ningful exceptions (nicolas-grekas)

This PR was merged into the 3.4 branch.

Discussion
----------

[TwigBundle/Brige] catch missing requirements to throw meaningful exceptions

| Q             | A
| ------------- | ---
| Branch?       | 3.4
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #25256, symfony/webpack-encore#173
| License       | MIT
| Doc PR        | -

It is possible to register a handler for undefined twig functions/filters.
IMHO, this is the hook point we should leverage to throw meaningful exception messages.

This works well on its own. We now just need to list the functions/filters with appropriate messages.

There is one case we could enhance: at warmup time, Twig exceptions are swallowed, thus not visible.
Shouldn't we make these visible instead?

ping @weaverryan since this is related to two issues of yours.

Commits
-------

ac891ac [TwigBundle/Brige] catch missing requirements to throw meaningful exceptions
@sroze
Copy link
Contributor

sroze commented Dec 30, 2017 via email

@weaverryan
Copy link
Member Author

Well, it was solved for Twig filters/functions specifically.... So the question now is: can/should we just continue to solve these issues one-at-a-time as we discover them? Or should we add a more over/arching system.

Right now... I can’t be sure... but I think we may be able to solve this on a case-by-case basis.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
DX DX = Developer eXperience (anything that improves the experience of using Symfony)
Projects
None yet
Development

No branches or pull requests

5 participants