📌 Discussion: Which require- and valid- rules should be in the recommended config?

[michaelfaith]

Now that we've landed on a long-term strategy for the require- and valid- flavor of rules. I'd like to start the discussion of which require- and valid- rules should we include in the recommended config?

I'll start a table here with all that have issues created, and we can use this thread to discuss which of them should belong in the config and which shouldn't.

Require

rule	issue	recommended
require-author	#795
require-bin	#796
require-bugs	#862
require-bundleDependencies	#797
require-config	#798
require-contributors	#799
require-cpu	#800
require-dependencies	#863
require-description	#864	✅
require-devDependencies	#801
require-directories	#802
require-engines	#868
require-files	#803
require-funding	#804
require-homepage	#865
require-keywords	#866
require-license	#846	✅
require-main	#805
require-man	#806
require-module	#807
require-name	#808	✅
require-optionalDependencies	#809
require-os	#810
require-peerDependencies	#811
require-preferGlobal	#812
require-private	#813
require-publishConfig	#814
require-repository	#867
require-scripts	#815
require-type		✅
require-types	#816
require-version	#817	✅

Valid

rule	issue	recommended
valid-author	#840	✅
valid-bin	#818	✅
valid-bundleDependencies	#819	✅
valid-config	#820	✅
valid-cpu	#821	✅
valid-dependencies	#822	✅
valid-description	#823	✅
valid-devDependencies	#824	✅
valid-directories	#825	✅
valid-exports		✅
valid-files	#827	✅
valid-homepage	#828	✅
valid-keywords	#829	✅
valid-license	#830	✅
valid-main	#831	✅
valid-man	#832	✅
valid-module		✅
valid-optionalDependencies	#833	✅
valid-os	#834	✅
valid-peerDependencies	#835	✅
valid-preferGlobal	#836	✅
valid-private	#837	✅
valid-publishConfig	#841	✅
valid-repository	#838	✅
valid-scripts	#839	✅
valid-type	#842	✅
valid-workspaces	#843	✅

[michaelfaith]

I'd nominate (at least) the following require rules be included in recommended:

• description
• license
• main
• name
• type
• version

[JoshuaKGoldberg]

Thinking on https://docs.npmjs.com/creating-a-package-json-file:

• Immediate 👍 on name and version as they're required
• The page also explicitly recommends description, 👍

👍 on license and type too. Licensing is important, and I have hope that eventually type will be a recommended property added by npm init by default per nodejs/TSC#1445.

main I'm not convinced though:

• It's permissible to use exports instead: https://nodejs.org/api/packages.html#exports
• Not every app is meant to have a main - e.g. a team's end React app that's deployed as a site

I think instead of blanket requiring the main field, we'd probably want to enable rules that make sure any bin, exports, main, etc. are valid if they exist.

[michaelfaith]

RE: type, I was basing that on this recommendation from Node's page on modules: https://nodejs.org/api/packages.html#introduction_1

In particular, package authors should always include the "type" field in their package.json files, even in packages where all sources are CommonJS. Being explicit about the type of the package will future-proof the package in case the default type of Node.js ever changes, and it will also make things easier for build tools and loaders to determine how the files in the package should be interpreted.

For main: that's fair. It's not strictly required, but I was thinking more about backwards compatibility there. Building a package that supports as broad combability as possible with both old and new module resolution settings usually means including main (generally always), module (if it's type: module), types (when types are included), along with exports. Leaving main off will mean older module resolutions and certain tooling won't work well with it. (e.g. the import eslint plugin).

So I guess that brings up a good question, what is the aim of our recommendation? I think one of the goals could be properties that contribute to improved compatibility.

[JoshuaKGoldberg]

backwards compatibility

Proposal: how about sticking with Node LTS? I know other plugins such as import go for much longer trails of backwards compatibility, but I'm not a fan of that strategy. It means the packages have to do a lot of work to support older clients/versions and oftentimes can't fully update their recommended presets to the latest versions. For example, for Node LTS...

Leaving main off will mean older module resolutions and certain tooling won't work well with it. (e.g. the import eslint plugin).

...exports has been supported since Node 12.7.0 (https://nodejs.org/api/packages.html#exports). 12.20 and 14.13.0 added patterns. LTS starts at 18 right now. If we can assume LTS support, we don't need to consider backwards compatibility with main in our recommended preset - thus simplifying it.

[JoshuaKGoldberg]

Oh and about the Valid table: should these all just be enabled? If the field exists we'd want to validate it by default, right?

[michaelfaith]

Oh and about the Valid table: should these all just be enabled? If the field exists we'd want to validate it by default, right?

I think that makes sense