-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Build Tools: Install Composer dependencies as pre-lint step #21537
Conversation
Size Change: 0 B Total Size: 903 kB ℹ️ View Unchanged
|
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'm OK with this.
Noting that there's some related work happening in #20280 and #20090, at least regarding making the environment consistent between Travis and local development, in order to avoid these weird developer experience barriers of getting the tests to run the same way they do in continuous integration. That said, even as of those changes, the |
Hm. This doesn't seem to be working for me locally 🤔
|
It still fails just running |
@noahtallen Yeah, I've seen some similar issues with this lately. Which is odd, because as of these changes, Travis runs the lint through the exact same process. Do you get the same error when running |
Yep. It looks like docker compose includes a string as the I'll see what happens when we check to make sure that |
If we do that:
Looks a lot nicer, but it doesn't actually seem to be an error! |
Do you think the problem is that the presence of any output is being interpreted as an error? Even if it's not an error? |
It works correctly for other commands, so I'm not sure. I think |
I think this might just error out when there is nothing to install or update. It probably passes in CI since it does have stuff to install and update |
this should fix it: #22475 |
Fixes issues noticed in #21537 (comment).
For what it's worth, I'm not entirely loving the changes that were introduced here. At least in common usage, the I'm still not sure what the best solution here would be. It's a bit similar to needing to run |
I agree with you here. It makes no sense why composer takes 2-3 minutes to install when everything is already up to date. Maybe we could expose a package script to run composer install? At that point I think it’s fine to tell people they need to run it once before doing phpcs or phpunit |
I do think it's a simple option, but really only if it can be communicated effectively in a way which won't just be utterly confusing. I haven't looked into it, but one option could be to be more helpful in the error case, if there's some way that the failures associated with not having run this step can include a tip on what the developer needs to do to fix it. Example:
|
Yeah that would be really useful. Part of me thinks it would be really useful for wp-env too since phpcs and phpunit are very common use cases, but I'm not sure how to integrate those more closely |
Related:
This pull request seeks to install Composer dependencies as part of the PHP lint script. This is intended to improve the developer experience, where a default installation of the development environment would not allow for
npm run lint-php
to be run. This script assumes Composer dependencies to already have been installed. Unless the contributor explicitly installs these dependencies via the (undocumented)npm run wp-env run composer install
command, they cannot run the tests locally.These changes bring uniformity to how lint testing occurs between a contributor's environment and in Travis. Previously, our Travis environment was "privileged" to have these setup tasks run, but these setup tasks are not made available to standard contributors, nor are they documented.
Implementation Notes:
Very important to note: This changes Composer installation in Travis from using the (legacy?) "env" setup, to the new "wp-env" setup. It's most important in considering the potential impact of reintroducing the issue intended to have been addressed in #21118. Fortunately, it should be relatively obvious if there are any issues, since the Travis build would pass only if working correctly.
As illustrated by the above-referenced Slack discussion, I'm not particularly attached to this approach, but I do fear the developer experience is currently very lacking. It took me quite some time to figure out how to run PHP linting successfully. While this implementation can be "wasteful" in that it runs the composer install step even if dependencies are already installed, an alternative was not clear in how to reduce friction for contributors to run tests.
It should be relatively safe that this only applies to linting, since all of the Composer dependencies are specific to linting (source).
Possible alternatives could include:
npm install
before starting development work.wp-env
scripts could infer based on an incoming command whether it should need to prepare the environment to be able to run the command.npm run test-php
script:Testing Instructions:
npm run lint-php
.