Conversation
Codecov Report
@@ Coverage Diff @@
## master #55 +/- ##
===========================================
- Coverage 97.29% 81.81% -15.48%
===========================================
Files 17 19 +2
Lines 148 176 +28
Branches 41 48 +7
===========================================
Hits 144 144
- Misses 4 25 +21
- Partials 0 7 +7
Continue to review full report at Codecov.
|
|
@danielbachhuber, this is the proof of concept I wanted to share with you :) |
|
FYI: WordPress' official build tool is Grunt, and we've recently added Webpack. Official WordPress repos should use Grunt over Gulp, the reason for this is primarily to reduce the required volume of learning for contributors to WordPress projects. |
packages/a11y/package.json
Outdated
| }, | ||
| "dependencies": { | ||
| "@wordpress/dom-ready": "^0.1.0-beta.6" | ||
| "@wordpress/dom-ready": "0.1.0-beta.6" |
There was a problem hiding this comment.
This change shouldn't be in this PR should it?
There was a problem hiding this comment.
Likewise the dom-ready/package-lock.json and a11y/package-lock.json changes shouldn't be in this PR either?
There was a problem hiding this comment.
Yes, I will remove those changes.
The main goal of this package is to make it an implementation detail if WordPress is using Grunt, Gulp, Webpack or whatever is necessary to make things done. I can envision using all of those tools in this package, as well as having them replaced in the far future with something that is yet to be created. This approach promotes usage of npm run-script which is a well-established pattern in the JS community. |
f9f803d to
c1ad274
Compare
|
Can I use this and a Gruntfile in my own project? e.g. this project would expose some |
aaronjorbin
left a comment
There was a problem hiding this comment.
Loving this! Thanks for kicking it off.
| "scripts": { | ||
| "build-clean": "rimraf ./packages/*/build ./packages/*/build-module", | ||
| "build": "node ./scripts/build.js", | ||
| "postinstall": "lerna bootstrap --hoist && npm run build", |
There was a problem hiding this comment.
Is removing --hoist intentional?
There was a problem hiding this comment.
Yes, I opened an issue to address it separately #56. I will rebase once it gets merged.
|
|
||
| const pkg = grunt.file.readJSON( 'package.json' ); | ||
| const pluginSlug = grunt.option( 'pluginSlug' ) || pkg.name; | ||
| const textDomain = grunt.option( 'textDomain' ) || ''; |
There was a problem hiding this comment.
Should we start a standard of allowing package.json to contain a WordPress object that initially has textDomain and pluginSlug properties in it? pluginSlug could fallback to pkg.name if pkg.wordpress.pluginslug isn't defined.
There was a problem hiding this comment.
I'm more than happy to do it. I thought it might be too early, but if you raised that now let's go for it 💯
| const pluginSlug = grunt.option( 'pluginSlug' ) || pkg.name; | ||
| const textDomain = grunt.option( 'textDomain' ) || ''; | ||
|
|
||
| console.log( pluginSlug, textDomain ); |
| }, | ||
|
|
||
| wp_readme_to_markdown: { | ||
| your_target: { |
There was a problem hiding this comment.
This is another area where pkg.wordpress could come in handy, since it would allow screenshots to be passed in.
| Install the module | ||
|
|
||
| ```bash | ||
| npm install @wordpress/scripts --save |
There was a problem hiding this comment.
The PR summary contains the line: "To include you would have to include in devDependencies only this:"
Would --saveDev make more sense?
|
When this is available, let's make sure to announce it on https://make.wordpress.org/core and cross-post it on https://make.wordpress.org/plugins/ |
|
@adamsilverstein can we cover it with tests in some simple way? |
|
Probably worth mentioning wp-cli/ideas#68 Sorry I didn't connect the dots before. Given |
| "cross-spawn": "5.1.0", | ||
| "grunt": "1.0.1", | ||
| "grunt-wp-i18n": "1.0.1", | ||
| "grunt-wp-readme-to-markdown": "2.0.1" |
There was a problem hiding this comment.
Who maintains these dependencies, since now we're trying to build a utility hiding implementation details, we can try to move away from React, I think these would benefit from being simple Javascript Scripts instead of Grunt tasks.
Not saying we should do it now, the scripts module also allows us to keep using Grunt and several other tools and hide the implementation, but avoiding useless dependencies like "grunt" would be good (Same way there's babel, and grunt-babel etc...)
There was a problem hiding this comment.
@stephenharris is the maintainer.
In general, I agree that lessening the dependency on Grunt makes sense, but at the same time it's not exposed to the plugin developer, so it is just an implementation detail rather than an api detail.
So this would make this PR obsolete. I'd be more than happy to have that handled by |
Yes, it doesn't stop you from having your own Grunt setup in your project. The nice thing about |
I would support this. If wp-cli can be the tool of truth, I think it makes sense. |
|
Closing in favor of #62. |
Still work in progress ...
This implementation is based on the react-scripts. Grunt tasks are copied directly from
wp scaffold plugintemplates. See gruntfile for reference.The end goal would be to run it as:
wp-scripts i18n --pluginSlug=abc --textDomain=xyzwp-scritps readmeTo include you would have to include in
devDependenciesonly this:Disclaimer
I'm not promoting
Gruntby any means. It was easy to copy what we already have inwp-clito show how it could benefit plugin developers. Script names could be prefixed withplugin-in this case to make it more clear where it is applicable. This could also live inplugin-scriptspackage to avoid confusion.