Skip to content
This repository has been archived by the owner on Jul 9, 2018. It is now read-only.

Add @wordpress/npm-package-json-lint-config package #119

Merged
merged 14 commits into from
May 17, 2018

Conversation

ntwb
Copy link
Member

@ntwb ntwb commented May 6, 2018

This PR seeks to add a new package @wordpress/npm-package-json-lint-config

It implements a "shared config" for the package.json npm-package-json-lint linter

It is based on the upcoming currently unreleased v3 release of npm-package-json-lint

This was briefly discussed in last weeks #core-js chat

The benefit of being able to lint multiple package.json files allows us to ensure specific fields are included in our package.json files, for example, version, name, description, and publishConfig for Lerna which caught us out recently. npm-package-json-lint-config also triggers warnings and errors when fields use incorrect types, e.g. for when an object is expected yet an array is used for a package.json value. The configuration also forces an opinionated sort order of the package.json fields.

The shared configuration is relatively generic which will allow it to be used to validate WordPress projects package.json files, for example, core, bbPress, BuddyPress, Dashicons, grunt-patch-wordpress, and Gutenberg. For this repo the base configuration of @wordpress/npm-package-json-lint-config is extended by a npmPackageJsonLintConfig configuration option in the root package.json here.

This PR doesn't remove the manual check for publishConfig that was added in #115 as npm-package-json-lint currently only allows for checking if publishConfig exists, I've opened an issue here requesting that a valid-values-publishConfig rule be added so that we can enforce that the value of publishConfig is "access": "public"

@codecov
Copy link

codecov bot commented May 6, 2018

Codecov Report

Merging #119 into master will increase coverage by 0.09%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #119      +/-   ##
==========================================
+ Coverage   67.44%   67.53%   +0.09%     
==========================================
  Files          56       57       +1     
  Lines         688      690       +2     
  Branches      144      144              
==========================================
+ Hits          464      466       +2     
  Misses        182      182              
  Partials       42       42
Impacted Files Coverage Δ
packages/npm-package-json-lint-config/index.js 100% <100%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8a2dea2...63f6b74. Read the comment docs.

@@ -12,6 +12,7 @@ mkdirp( 'node_modules/@wordpress', () => {
[ 'packages/browserslist-config', 'node_modules/@wordpress/browserslist-config' ],
[ 'packages/babel-preset-default', 'node_modules/@wordpress/babel-preset-default' ],
[ 'packages/jest-preset-default', 'node_modules/@wordpress/jest-preset-default' ],
[ 'packages/npm-package-json-lint-config', 'node_modules/@wordpress/npm-package-json-lint-config' ],
Copy link
Member

Choose a reason for hiding this comment

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

I was wondering if we can create this list using glob?

Copy link
Member Author

Choose a reason for hiding this comment

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

Possibly, will follow up in another PR

@@ -0,0 +1,30 @@
{
"name": "@wordpress/npm-package-json-lint-config",
Copy link
Member

Choose a reason for hiding this comment

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

Any way we can enforce tabs for indentation? 😉

Copy link
Member Author

Choose a reason for hiding this comment

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

I've requested a new rule to prevent my future self facepalming:

tclindner/npm-package-json-lint#81

"type": "git",
"url": "git+https://github.com/WordPress/packages.git"
},
"bugs": {
Copy link
Member

Choose a reason for hiding this comment

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

Whitespace consistency.

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks, fixed in 963eae1

package.json Outdated
@@ -56,7 +56,7 @@
"check-engines": "check-node-version --package",
"create-symlinks": "node ./scripts/create-symlinks.js",
"lerna-bootstrap": "lerna bootstrap --hoist",
"npmpackagejsonlint": "npmPkgJsonLint ./packages -c .npmpackagejsonlintrc.json",
"npmpackagejsonlint": "npmPkgJsonLint ./packages",
Copy link
Member

@gziolo gziolo May 15, 2018

Choose a reason for hiding this comment

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

Should it be named lint-packages?

Copy link
Member Author

Choose a reason for hiding this comment

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

What about lint:pj, not that it is immediately obvious what actually infers I saw it the other day alongside lint:js, lint:md etc?

		"lint:js": "eslint .",
		"lint:css": "stylelint .",
		"lint:md": "remark-lint .",
		"lint:pj": "npmPkgJsonLint ./packages",
		"lint:scss": "stylelint --syntax=scss .",

Copy link
Member Author

Choose a reason for hiding this comment

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

Or lint:package maybe?, could be used with npm-run-all npm run all lint:*

Copy link
Member

Choose a reason for hiding this comment

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

lint:pkg-json should do the trick, and agreed on npm-run-all.

Copy link
Member

@gziolo gziolo left a comment

Choose a reason for hiding this comment

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

Let's proceed with this one. LGTM 👍

I left 2 nitpicks to address before merging.

@@ -0,0 +1,14 @@
'use strict';
Copy link
Member

Choose a reason for hiding this comment

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

I don't think we need to use use strict in JS file anymore, because we use es6 modules.

@@ -0,0 +1,14 @@
'use strict';

const config = require( '../' );
Copy link
Member

Choose a reason for hiding this comment

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

You can use import statement here.

@gziolo
Copy link
Member

gziolo commented May 17, 2018

is-plain-obj is not added as a dependency, but it works because it is included by something else 😄

@gziolo
Copy link
Member

gziolo commented May 17, 2018

I addressed my own comments, let's get it in to take advantage of linting :)

@gziolo gziolo merged commit 240be25 into master May 17, 2018
@gziolo gziolo deleted the add/npm-package-json-lint-config branch May 17, 2018 09:39
@@ -11,8 +11,10 @@
"check-node-version": "^3.1.1",
"codecov": "^2.3.1",
"glob": "^7.1.2",
"is-plain-obj": "^1.1.0",
Copy link
Member

Choose a reason for hiding this comment

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

Does this need to be defined as a devDependencies in the root if we're not using it in the root?

Copy link
Member

Choose a reason for hiding this comment

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

Package are local, tests are global, so we just need pick one approach for those dependencies. I have a feeling that other packages define them in their own package.json file. Lerna will hoist, them so we don't need it in here.

Copy link
Member

Choose a reason for hiding this comment

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

Okay. Seemed we should need it to be defined in either root or npm-package-json-lint-config/package.json, but not both.

Copy link
Member

Choose a reason for hiding this comment

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

Yes, one of them is enough.


describe( 'npm-package-json-lint config tests', () => {
it( 'should be an object', () => {
expect( isPlainObj( config ) ).toBeTruthy();
Copy link
Member

Choose a reason for hiding this comment

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

The toBeTruthy assertion should be discouraged, as it implies that we expect it could be a value other than explicitly true (a non-zero number, a non-empty string, etc). If we expect it should be explicitly true, we should assert as toBe( true ).

/**
* External dependencies
*/
import isPlainObj from 'is-plain-obj';
Copy link
Member

Choose a reason for hiding this comment

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

Minor: Not sure if introduction of dependency here is strictly necessary. What is it we're testing?

Would expect.toMatchObject( {} ) have been adequate, particularly if we don't care about subset of properties?

Alternatively, Lodash includes an _.isPlainObject as well, if we want to lean on Lodash as a canonical source of utility functions.

Thinking in terms of being explicit with where dependencies add value to avoid excessive proliferation.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants