-
-
Notifications
You must be signed in to change notification settings - Fork 67
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
Autoloading is broken when added as a project dependency #68
Comments
the background on this comes from trying to add this to https://github.com/acquia/blt so that we can provide a default validation, as we have with https://github.com/squizlabs/PHP_CodeSniffer and other validation libraries, to automatically check for deprecated code in custom modules and themes. |
I'm having the same problem. drupal-check works when using the .phar file, but when installed using composer on a project-level, as described in the README.md, i get "Class ... was not found while trying to analyse it - autoloading is probably not configured properly." Command I execute: Output:
|
Retitled. Needs test coverage. |
I am also having the same problem. I tried with |
@mikemadison13 can you link to the BLT issue that you're referencing in #68 (comment)? |
I don't have one open at the moment @JDDoesDev, I was trying to add it when removing the deprecation code and ran into this issue. I'm happy to write one if that would be useful, but since all of my efforts locally were failing (because of this issue) I hadn't taken it any farther on the BLT side. |
@mikemadison13 there is significant interest in this and a few of us are working on similar efforts. it may be in our best interest to try and put our heads together on it. if you do create an issue, please link it and i will pass it along to a few other people who are trying to come up with similar solutions. |
ok cool! I definitely want to try and fit the use case of "regular" checks for deprecated code in custom modules so that devs are warned on an ongoing basis if they are committing it. i found similar issues in the phpstan issue queue so this may not technically be "just a drupal-check" issue. |
@mikemadison13 thanks for the update! please feel free to tag me on the BLT issue if it gets created and I can pass it along and maybe get a few more eyes on the project if you're interested. |
I experience the same issue when installing globally via: The phar works fine. |
I've also got the same issue with both global and local composer installs, I haven't tried the phar approach. |
Following this issue as we have the same error when using this package locally & globally. Note that in order to work around this issue I had to remove it first:
And then install it using the phar:
|
Can you test against https://github.com/mglaman/drupal-check/releases/tag/1.0.10 ? |
I added to a project and am still getting similar results:
I ran:
|
I'm having much better results. I just added mglaman/drupal-check to a project with
I then went into the web directory (it is a drupal-composer project) and ran
I got:
|
Seems to work splendid, thanks! Note that you may want to advise using this project as a dev dependency, see #87. |
Apologies, I forgot I still had the global version installed. Running out of I did get an error at one point that killed my progress on contrib modules.
|
So it seems like everything is OK here. I'm going to close. Let me know if there is still something wrong. @mikemadison13 that error is a legit PHP error caused by the libraries module (probably dead code which never runs and bug never found) |
FYI BLT merged this feature in a few days ago. It can be manually patched into BLT 10.x and will be available in the next 10.x release (note that it must be enabled for both modules and themes). thanks so much @mglaman for the work on this! super excited to have this be a part of our automated testing suite. |
We are still getting the same error with v1.0.14 and BLT v10.5.0 |
I've managed to fix my issues by checking (and correcting) carefully all class namespaces (and @Package tags) under the question. |
note that I had this issue recently as well, and as @jabxjab mentioned it was because of improperly namespaced files / bad use statements. In this case I believe the error was legit, nothing to be fixed as far as I can tell. |
Related to #55 but for custom modules, not contrib.
While running
drupal-check docroot/modules/custom
, I am getting<class> was not found while trying to analyse it - autoloading is probably not configured properly.
for each of my custom modules.I understand for contrib why this might be a thing, but for the custom modules I don't expect them to ever be autoloaded (since they weren't adding with composter).
I have tried to do this both from the project level and globally. I know @mglaman suggests doing it globally. It would be really nice if we could require this library at the project level, so that it is one less global dependency that everyone has to install, CI has to install, etc.
composer install
at the project level would be a really ideal way to pull in this library!The text was updated successfully, but these errors were encountered: