-
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
Improved composer.json file #1229
Conversation
Added more information, the "wordpress-plugin" package type, and other required things to make installing the plugin via composer easier.
Thanks for the PR. I don't think it was a goal to make the plugin installable via composer. The Is there a way to define a prepublish build step for composer? Do we really expect this plugin to be installed using composer? |
Yes. Actually, there is one already. There is a |
@youknowriad - I sorry, I didn't realize you don't include the build files in the base repo. I looked for a few minutes for that explanation somewhere in the docs, how to get started or build the files, but I I don't see that. Would you like me to add some documentation for that as well? Anyways, I'll need to update this PR in order for this to work regardless. Like @westonruter said we could use a |
CONTRIBUTING.md includes some information about building the plugin from source files. We could perhaps do a better job of highlighting the fact that the source files are not usable out-of-the-box. |
I feel like it's totally possible to do a post-install, but if you all think this might be too much to expect out of this repo (for now), I'm okay with a close and I'll just install from wpackagist. |
I'd say the License should be Here's a potential improvement to the "scripts": {
"build": "npm install",
"install-standards": "\"vendor/bin/phpcs\" --config-set installed_paths ../../wp-coding-standards/wpcs",
"post-install-cmd": [
"@install-standards",
"@build"
]
}
|
@GaryJones great point on the composer commands - wouldn't we want "build" to run |
Er...yup :-) You could probably have the install (or update) and build on |
Composer could be better explained in our docs. In particular for those who come from JavaScript world. We might also consider providing a two way integration between JavaScript and PHP. Similar to what is proposed above for Composer, we could add an alternative command which would bootstrap composer :) It might be too confusing though, but we can always discuss pros and cons. |
composer.json
Outdated
"dealerdirect/phpcodesniffer-composer-installer": "^0.4", | ||
"squizlabs/php_codesniffer": "2.9.x", | ||
"wimg/php-compatibility": "dev-master", | ||
"wp-coding-standards/wpcs": "^0.11.0" |
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.
The latest released version of WPCS is 0.14.0
, so ideally this would be the minimum version here.
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.
Fixed by 4e4055f
composer.json
Outdated
"scripts": { | ||
"lint": "phpcs", | ||
"post-install-cmd": [ | ||
"phpcs --config-set installed_paths ../../wp-coding-standards/wpcs/" |
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.
With the DealerDirect plugin, this script is no longer needed (and it doesn't register PHPCompatibility standard anyway).
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.
Removed in 7247134
You cannot assume that |
Codecov Report
@@ Coverage Diff @@
## master #1229 +/- ##
==========================================
- Coverage 37.7% 31.51% -6.19%
==========================================
Files 279 238 -41
Lines 6737 6686 -51
Branches 1226 1199 -27
==========================================
- Hits 2540 2107 -433
- Misses 3536 3849 +313
- Partials 661 730 +69
Continue to review full report at Codecov.
|
@atimmer - makes sense. I'll write a check to see if |
Okay. I'm still working on the script to check for Got another question for you though. Should we run |
composer.json
Outdated
"issues": "https://github.com/WordPress/gutenberg/issues" | ||
}, | ||
"require-dev": { | ||
"dealerdirect/phpcodesniffer-composer-installer": "^0.4", |
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.
The early 0.4.*
releases had a couple of bugs. The constraint should allow the most recent anyway, but worth specifying ^0.4.3
just to be sure?
composer.json
Outdated
}, | ||
"require-dev": { | ||
"dealerdirect/phpcodesniffer-composer-installer": "^0.4", | ||
"squizlabs/php_codesniffer": "2.9.x", |
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.
What was the reason for staying on the 2.9.x branch?
FWIW, the recent patch that fixed a load of code standards in WP core relied on 3.2.0-dev (master
) for PHPCS.
WPCS, PHPCompatibility and the DealerDirect plugin work fine with the PHPCS 3.1.1 (stable release).
A constraint of ^3.1
would be fine.
composer.json
Outdated
"require-dev": { | ||
"dealerdirect/phpcodesniffer-composer-installer": "^0.4", | ||
"squizlabs/php_codesniffer": "2.9.x", | ||
"wimg/php-compatibility": "dev-master", |
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.
The current release is 8.0.1
, and it now follows semantic versioning, so maybe go with ^8
as the version constraint here?
composer.json
Outdated
"composer/installers": "~1.0" | ||
}, | ||
"scripts": { | ||
"lint": "phpcs" |
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.
PHPCS does more than lint, and adding a script that then expects composer lint
, instead of just the single command phpcs
seems a little redundant.
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.
Totally agreed. I'll remove it.
Thanks to @GaryJones for the recent updates and code checks. Those shouldn't be too much effort at all to update, many of the specific versions were just left over from my initial PR, which was during WordCamp Europe, so totally outdated. That said, I've thought a bit more about this PR on the drive home today. A script to check for npm install would be needed for sure, so that the build can happen after an install or update, but to ensure a cross-platform solution (macOS, linux, windows) might be difficult. I'm still doing research on how to pull it off. While it might be beneficial to pull Gutenberg via composer, it is possible via wp-packagist where it's already built. It's honestly not super common in my experience using composer for it to even run a npm install. I suppose what I'm asking is: is the npm building/composer require-ability of this PR even worth it, or is there a better way to solve this problem? Thanks! |
I think there is enough value in the current PR to consider it done (with amendments), and leave the NPM stuff to another PR. |
There are |
This leads to another question, should we integrate |
@GaryJones looks like that last build didn't work because:
But I ran everything locally and follow these instructions just to double-check. Seems to work great. Any thoughts? Maybe Travis has some type of cache? Or did I actually miss a step? Thanks. |
As for the other stuff...
I've made those amendments. I totally agree with you. However I think we should have some kind of note that the build files are not build on Good points above @gziolo. I think running from package.json would be fine. There are many ways to skin this cat. But I still think we need to think hard about how to make that work for everyone. Once this PR is merged in with the basic changes I'm happy to open a new ticket to brainstorm how we might accomplish this.
Good question! Maybe a topic for another issue? |
It seems it does. The DealerDirect plugin should re-register the standards on One workaround (well, documented feature that says it's for CIs) would be to add a manual script to {
"scripts": {
"install-codestandards": [
"Dealerdirect\\Composer\\Plugin\\Installers\\PHPCodeSniffer\\Plugin::run"
]
}
} Then, in |
As all efforts to restart the failing Travis job have failed I added a commit to change the license to Following #3837 Travis CI no longer caches Composer's Edit: All Travis CI jobs are now passing 📗 |
Who needs eyes on this to merge it? (And why does the |
As the project nears merging with WP Core I'm sure this policy will change... |
Thanks for everyone's work on this! I will keep thinking about how to run an automatic Should we mention something in the README about needing to build npm stuff if you use composer to install this as a plugin? (like in Bedrock or something like that?) |
Added more information, the "wordpress-plugin" package type, and other required things to make installing the plugin via composer easier.
Of course the plugin will need to get registered on packagist but this gets us started.
I also would like to double-check the license is GPL2 vs 3 (see here) and then I will add a PR for a license.md file.
Cheers 🍻