-
Notifications
You must be signed in to change notification settings - Fork 4.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
Add "components" docs #8337
Add "components" docs #8337
Conversation
…file, any change to the docs tooling, and package files that would likely require rebuilding the docs. Also automated running of js and package.json linting. All occurs on a pre-commit hook.
}, | ||
"lint-staged": { | ||
"packages/*/package.json": [ | ||
"wp-scripts lint-pkg-json" |
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.
We should rather use npm run lint-pkg-json
in here to ensure it always uses the universal command.
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.
@gziolo If we do that, then it will run for all of the package.json files and not just the ones that have changed.
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.
Right, I didn't think about it. Good call 👍
"wp-scripts lint-pkg-json" | ||
], | ||
"*.js": [ | ||
"eslint" |
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.
We should rather use npm run lint-js
in here to ensure it always uses the universal command.
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.
@gziolo If we do that, then it will run for all of the JavaScript files and not just the ones that have changed. It is very slow when scanning everything.
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.
Essentially the lint staged tool will automatically pass the files that have changed to the command. Because the npm run lint-js
script passes .
as the path, it will cause it to run eslint
against all .js
files in the project. By just using the eslint
command here, only the files that have changed are linted. Besides, we don't want linting problems caused by someone else's commit to prevent our own.
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.
Unless you use git add -p
for partially staging files, if you do stage files in this manner lint-staged
is unable to detect the difference.
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.
Aside: we need wp-scripts lint-js
anyways, that would be a way to provide one interface in the long run.
package.json
Outdated
"*.js": [ | ||
"eslint" | ||
], | ||
"{docs/{root-manifest.json,tool/*.js},packages/{*/src/{actions,selectors}.js,components/src/*/README.md}}": [ |
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 bet this should include all type of README.md
files located inside packages
folder.
We should also update when new packages/*/README.md
is added.
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.
Is it overkill to run this on every commit? How long does this task take to run?
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 think it only generates manifest.json
file. It's super fast.
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.
…en `Components Package Reference`
@gziolo I've pushed an update to the PR... would love to get a final review from you. Should I also wait on the other reviewers you added before we merge? |
docs/tool/config.js
Outdated
@@ -3,15 +3,17 @@ | |||
*/ |
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.
This is meant to be a "config" file, I'd personally move all the logic to generate the manifest to docs/tool/manifest.js
and leave here only the parts that are "configurable"
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 guess the line is not always easy to draw. We should probably rethink this config globally though. So don't take this comment as a big blocker.
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.
That is what I was going to do initially, but that file exports a single function that is very specific to the logic for the packages and data docs. I considered exporting an object from that file which contained more than one function but went the path of least resistance. I'd be happy to make some changes if you have a specific recommendation.
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.
Since the function is already doing two things, it can do three :) and we can split it into three functions if necessary.
I'd only keep 'packages/components/src'
as a config variable. Something like: componentsSource
or something like that, and just move everything else to manifest.js
.
Also it looks like the baseRepoUrl
is already being used in that file (hardcoded), so it might be good to use this variable consistently.
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.
Let's address this feedback and 🚢
I really like the automation proposed in this PR 💯
…nerated manifest from config.js. Regenerated docs.
@youknowriad If you can give this a final review, I'd appreciate it. Thanks! |
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.
Nice work
|
||
return packagesManifest.concat( dataManifest ); | ||
module.exports = { | ||
getPackageManifest: function( packagesConfig ) { |
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.
Minor; I would have moved those functions above (and added JSDocs) and only export the getManifest
concatenating the three manifests.
I tried to resolve conflicts using GitHub UI: c2287a9. Not sure if it is perfect though :) |
Applied two more commits to include the latest generated version of files. |
Another merge conflict resolved. I will merge it as soon as Travis is happy. Great work @wpscholar. Let's iterate on it in the follow-up PRs. I think we should add support in pre-commit hook for |
Description
Autogenerate components documentation. Pulls in all readme files from https://github.com/WordPress/gutenberg/tree/master/packages/components and automatically adds them to the Gutenberg docs. Implemented
lint-staged
andhusky
pre-commit hook to automatically run a build of the docs in the event that a file has changed that will likely result in a need for rebuilding the docs. Additionally, I automated validation of package.json files and linting of JS files that have changed.Fixes #4952
How has this been tested?
I've manually tested the scripts and can see the appropriate entries added to the manifest.json file. I've also tested the
lint-staged
pre-commit hooks to ensure that they work properly.Types of changes
New feature
Checklist: