-
Notifications
You must be signed in to change notification settings - Fork 9.3k
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
Setup:di:compile verbosity does nothing #35391
Comments
Hi @adamlavery. Thank you for your report.
Make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, Add a comment to the issue:
For more details, review the Magento Contributor Assistant documentation. Add a comment to assign the issue: To learn more about issue processing workflow, refer to the Code Contributions.
🕙 You can find the schedule on the Magento Community Calendar page. 📞 The triage of issues happens in the queue order. If you want to speed up the delivery of your contribution, join the Community Contributions Triage session to discuss the appropriate ticket. ✏️ Feel free to post questions/proposals/feedback related to the Community Contributions Triage process to the corresponding Slack Channel |
Hi @engcom-Charlie. Thank you for working on this issue.
|
✅ Jira issue https://jira.corp.magento.com/browse/AC-5994 is successfully created for this GitHub issue. |
✅ Confirmed by @engcom-Charlie. Thank you for verifying the issue. |
That is not testing a code error. The point is when di:com fails it should provide adequate information to identify where the issue is. |
Hello @, As I can see this issue got fixed in the scope of the internal Jira ticket AC-5994 by the internal team Based on the Jira ticket, the target version is 2.4.6. Thanks |
Summary (*)
setup:di:compile produces no useful output when there is a coding error. Using -v, -vv, -vvv or --verbose does nothing to help. The stack trace doesn't identify the file being processed let alone the source line of the error. If we've uploaded multiple files, none of which show any error in the code editor, we have no indicators where to find the code error.
Examples (*)
Nothing here indicates where the error is.
Proposed solution
As a minimum, the ClassLoader must identify the class it is trying to load. Preferably it would also include the line that generated the error.
The text was updated successfully, but these errors were encountered: