README overhaul #6
Conversation
|
I accidentally also deleted:
Questions:
|
A command which users can build themselves. 😉
By opening the WDT. Users familiar with Symfony should recognize the UI straight away, don't you think? |
Indeed :-) |
|
Hallo Thomas, Thanks for your changes. Aside from some details I've noted in the review, I'm happy to merge this. |
Just to be clear: I've never actually worked on a Symfony project, so I don't know how best to integrate TwigQI. Symfony automatically injects / auto-wires a I agree though that the errors are not really prominently displayed this way. This approach does have one advantage (although I could be wrong about that), which is that the error page can only display a single error, while the WDT can display many. @axel37, do you have an opinion here? |
While I agree that TwigQI inspections showing up in the debug toolbar is useful, I don't think that this fits the primary use case of most users. Displaying the results in the toolbar or throwing an error (= the application must be running) doesn't seem like the best interface for such a tool. Indeed, if you look at similar projects like phpstan or PHP-CS-Fixer (which are both tools that report issues in your code), they're both invoked with a console command. Having a command is very convenient since it can be used anywhere, like in a build/test pipeline or locally while developing. Some tools can even format their outputs so it can be fed to gitlab* reports (though that's not as important). I'm taking gitlab as an example because that's what I'm most familar with. To recap, it would be great to be able to run TwigQI independently of the application (something like |
I'd argue that it is while you're developing the template, including the
I totally agree, and it is now, but no batteries are included yet. Let's continue that conversation in #7. Do you have any opinion or preference with regards to logging in run-time, web dev mode? |
I agree that displaying inspection errors in the symfony toolbar is useful (I'm not sure about throwing an error, but it could be a matter of configuration). I can even imagine having a a custom toolbar section to make inspection results immediately evident (instead of keeping them tucked away in the logs page), but that's extra work ^^ |
What I did:
class TwigQIExtensionapproach (overservices.yaml), cause I'm suspecting that for the nearer future, there will be a come and go of inspections, so taking all is not a good idea (yet).class TwigQIExtension.What you should do:
class TwigQIExtension. Suggestion: Merge the explanations in the list of inspections into that copy-template like so:class TwigQIExtension: Add how to pass the logger to the functions.