Skip to content
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

Merged
merged 18 commits into from
Aug 8, 2018
Merged

Conversation

wpscholar
Copy link
Member

@wpscholar wpscholar commented Jul 31, 2018

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 and husky 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:

  • My code is tested.
  • My code follows the WordPress code style.
  • My code follows the accessibility standards.
  • My code has proper inline documentation.

…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.
@wpscholar wpscholar added the [Type] Developer Documentation Documentation for developers label Jul 31, 2018
@wpscholar wpscholar self-assigned this Jul 31, 2018
@wpscholar wpscholar requested a review from gziolo July 31, 2018 20:50
@gziolo
Copy link
Member

gziolo commented Aug 1, 2018

Awesome work. I will try to review this PR later this week 💯

By the way, @mmtr is working on improvements for the documentation of components. Both #8267 and #8338 should be good PRs to test together with those changes.

@gziolo gziolo requested review from pento, tofumatt, youknowriad and a team August 1, 2018 05:28
@gziolo gziolo added the [Type] Build Tooling Issues or PRs related to build tooling label Aug 1, 2018
@gziolo gziolo requested a review from ntwb August 1, 2018 05:28
},
"lint-staged": {
"packages/*/package.json": [
"wp-scripts lint-pkg-json"
Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member

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"
Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member Author

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.

Copy link
Member

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.

See lint-staged/lint-staged#62

Copy link
Member

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}}": [
Copy link
Member

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.

Copy link
Member

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?

Copy link
Member

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ntwb It only runs if a file has changed that matches the patterns listed here. It is also super fast.

@gziolo Agreed.

@gziolo gziolo added this to the 3.5 milestone Aug 1, 2018
@wpscholar
Copy link
Member Author

@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?

@@ -3,15 +3,17 @@
*/
Copy link
Contributor

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"

Copy link
Contributor

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.

Copy link
Member Author

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.

Copy link
Contributor

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.

Copy link
Member

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 💯

@wpscholar
Copy link
Member Author

@youknowriad If you can give this a final review, I'd appreciate it. Thanks!

Copy link
Contributor

@youknowriad youknowriad left a 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 ) {
Copy link
Contributor

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 getManifestconcatenating the three manifests.

@gziolo
Copy link
Member

gziolo commented Aug 8, 2018

I tried to resolve conflicts using GitHub UI: c2287a9. Not sure if it is perfect though :)

@gziolo
Copy link
Member

gziolo commented Aug 8, 2018

Applied two more commits to include the latest generated version of files.

@gziolo
Copy link
Member

gziolo commented Aug 8, 2018

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 stylelint which was added today by @noisysocks.

@gziolo gziolo merged commit b1196b8 into WordPress:master Aug 8, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Type] Build Tooling Issues or PRs related to build tooling [Type] Developer Documentation Documentation for developers
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants