📌 Tracking issue: comparison with equivalent other tools

[JoshuaKGoldberg]

Spinning out of #28: I want to make sure that all the nice features that other tools in the ecosystem have are considered in this repository.

👋 If you're a maintainer of any of the referenced packages then please reach out to me (I believe I've emailed you and/or pinged you in your issue tracker). I'd love to work with you on deduplicating rule implementations!

Note that this table is accurate only to my interpretation of each rule's intent - not necessarily their implementation details. For example, this package's valid-package-def might not capture every npm-package-json-lint *-type validation it's mentioned alongside. If you spot a gap in this package I'd encourage you to file a bug or feature request to fill it in.

⚠️ This is a big table and susceptible to human error. Please say something if anything is amiss!

Area emoji key:

• 🗺️: Schema validation
• 🧼: Cleanliness
• 🗜️: Version restrictions
• 📐: Sorting
• 🙅: Property restrictions
• 🧹: Whitespace formatting

Package emoji key:

• ✅: All equivalent rules have been implemented
• ✔️: All rules that would be in a recommended preset have been implemented

Area	Config	This package	eslint-plugin-json-files ✔️	eslint-plugin-node-dependencies	fixpack	npm-package-json-lint ✔️
🗺️	✔️	#48		compat-engines
🗺️	✔️	#49		valid-semver
🗺️	✔️	unique-dependencies	require-unique-dependency-names	no-dupe-deps		no-repeated-dependencies
🗺️	✔️	valid-local-dependency
🗺️	✔️	valid-package-def & #818				bin-type
🗺️	✔️	valid-package-def & #819				bundledDependencies-type
🗺️	✔️	valid-package-def & #820				config-type
🗺️	✔️	valid-package-def & #821				cpu-type
🗺️	✔️	valid-package-def & #822				dependencies-type
🗺️	✔️	valid-package-def & #823				description-type
🗺️	✔️	valid-package-def & #824				devDependencies-type
🗺️	✔️	valid-package-def & #825				directories-type
🗺️	✔️	valid-package-def & #826				engines-type
🗺️	✔️	valid-package-def & #827				files-type
🗺️	✔️	valid-package-def & #828				homepage-type
🗺️	✔️	valid-package-def & #829				keywords-type
🗺️	✔️	valid-package-def & #830				license-type
🗺️	✔️	valid-package-def & #831				main-type
🗺️	✔️	valid-package-def & #832				man-type
🗺️	✔️	valid-package-def & valid-name				name-type
🗺️	✔️	valid-package-def				no-duplicate-properties
🗺️	✔️	valid-package-def & #833				optionalDependencies-type
🗺️	✔️	valid-package-def & #834				os-type
🗺️	✔️	valid-package-def & #835				peerDependencies-type
🗺️	✔️	valid-package-def & #836				preferGlobal-type
🗺️	✔️	valid-package-def & #837				private-type
🗺️	✔️	valid-package-def & #838				repository-type
🗺️	✔️	valid-package-def & #839				scripts-type
🗺️	✔️	valid-package-def & #840				valid-values-author
🗺️	✔️	valid-package-def & #826				valid-values-engines
🗺️	✔️	valid-package-def & #830				valid-values-license
🗺️	✔️	valid-package-def				valid-values-name-scope
🗺️	✔️	valid-package-def				valid-values-private
🗺️	✔️	valid-package-def				valid-values-publishConfig
🗺️	✔️	valid-package-def & valid-version				version-type
🧼		#51				prefer-scripts
🧼		#795				require-author
🧼		#796				require-bin
🧼		#797				require-bundledDependencies
🧼		#798				require-config
🧼		#799				require-contributors
🧼		#800				require-cpu
🧼		#801				require-devDependencies
🧼		#802				require-directories
🧼		#803				require-files
🧼		#804				require-funding
🧼		#805				require-main
🧼		#806				require-man
🧼		#807				require-module
🧼		#808				require-name
🧼		#809				require-optionalDependencies
🧼		#810				require-os
🧼		#811				require-peerDependencies
🧼		#812				require-preferGlobal
🧼		#813				require-private
🧼		#814				require-publishConfig
🧼		#815				require-scripts
🧼		#816				require-types
🧼		#816				require-typings
🧼		#817				require-version
🧼		#862			✔️	require-bugs
🧼		#863			✔️	require-dependencies
🧼		#864			✔️	require-description
🧼		#865			✔️	require-homepage
🧼		#866			✔️	require-keywords
🧼		#867			✔️	require-repository
🧼		#51	ensure-volta-extends
🧼		#868	require-engines			require-engines
🧼		#846	require-license		✔️	require-license
🧼		#				description-format
🧼	✔️	valid-name				name-format
🧼	✔️	valid-version				version-format
🧼	✔️	valid-repository-directory	ensure-repository-directory			require-repository-directory
🧼	✔️	order-properties				prefer-property-order
🗜️		#54				no-restricted-dependencies
🗜️		#54				no-restricted-devDependencies
🗜️		#54				no-restricted-pre-release-dependencies
🗜️		#54				no-restricted-pre-release-devDependencies
🗜️		#54	no-branch-in-dependencies
🗜️		#54	restrict-ranges			no-archive-dependencies
🗜️		#54	restrict-ranges			no-archive-devDependencies
🗜️		#54	restrict-ranges			no-caret-version-dependencies
🗜️		#54	restrict-ranges			no-caret-version-devDependencies
🗜️		#54	restrict-ranges			no-file-dependencies
🗜️		#54	restrict-ranges			no-file-devDependencies
🗜️		#54	restrict-ranges			no-git-dependencies
🗜️		#54	restrict-ranges			no-git-devDependencies
🗜️		#54	restrict-ranges			no-tilde-version-dependencies
🗜️		#54	restrict-ranges			no-tilde-version-devDependencies
🗜️		#54	restrict-ranges			prefer-no-version-zero-dependencies
🗜️		#54	restrict-ranges			prefer-no-version-zero-devDependencies
🗜️		#54	restrict-ranges	absolute-version		no-absolute-version-dependencies
🗜️		#54	restrict-ranges	absolute-version		no-absolute-version-devDependencies
🗜️		#54	restrict-ranges	absolute-version		prefer-absolute-version-dependencies
🗜️		#54	restrict-ranges	absolute-version		prefer-absolute-version-devDependencies
🗜️		#54	restrict-ranges	prefer-caret-range-version		prefer-caret-version-dependencies
🗜️		#54	restrict-ranges	prefer-caret-range-version		prefer-caret-version-devDependencies
🗜️		#54	restrict-ranges	prefer-tilde-range-version		prefer-tilde-version-dependencies
🗜️		#54	restrict-ranges	prefer-tilde-range-version		prefer-tilde-version-devDependencies
📐	✔️	sort-collections				prefer-alphabetical-bundledDependencies
📐	✔️	sort-collections				prefer-alphabetical-dependencies
📐	✔️	sort-collections				prefer-alphabetical-devDependencies
📐	✔️	sort-collections				prefer-alphabetical-optionalDependencies
📐	✔️	sort-collections				prefer-alphabetical-peerDependencies
📐	✔️	sort-collections				prefer-alphabetical-scripts
🙅		#51				prefer-no-contributors
🙅		#51				prefer-no-dependencies
🙅		#51				prefer-no-devDependencies
🙅		#51				prefer-no-engineStrict
🙅		#51				prefer-no-optionalDependencies
🙅		#51				prefer-no-peerDependencies
🧹		(n/a)			✔️

I also looked at:

• https://github.com/azeemba/eslint-plugin-json#individual-rules: none seemed relevant here
• https://ota-meshi.github.io/eslint-plugin-jsonc/rules: none seemed relevant here

[JoshuaKGoldberg]

As of merging #135, I believe all the recommended-preset-level rules from eslint-plugin-json-files and npm-package-json-lint are implemented here! 🙌

That means JoshuaKGoldberg/create-typescript-app#839 is now unblocked.

[KristjanESPERANTO]

Just an idea: I'm using normalize-package-data in one project. It is not an ESLint package, but it makes some interesting things from which one might draw inspiration 🙂 Or would it be possible to create rules that use this package?

[JoshuaKGoldberg]

Ooh interesting, I hadn't seen that package. Looks useful!

There might be some use in standardizing files, yeah. #85 is another example of an equivalent package being mentioned as something we may want in this repo. I'd suggest the same thing for any new tool: file an issue with the suggested new rules.

Some initial thoughts looking through its README: it looks like a lot of the rules are around standardization and data validity checking. For standardization, I think it'd be reasonable to take any where the standardized version is objectively cleaner (e.g. #71). For validity, as long as it's a clearly more-valid form (e.g. #134). But I haven't put much thought into this - definitely interested in other points of view!

[tommy-mitchell]

Another one is pkg-ok, which for example ensures that files referenced in package.json exist.

[JoshuaKGoldberg]

Ah sorry I dropped responding to pkg-ok note. It's a nice idea but the tricky thing is that a lot of packages refer to files that don't exist during development. I'm going to hold off adding that to this table - but if you want to talk about adding it in, I'd be interested in seeing a separate issue. Thanks!

[AndreaPontrandolfo]

03/10/2024, ESLint released it's official package for supporting JSON files.

@eslint/json.

Shouldn't this package adopt that package under the hood now?

[JoshuaKGoldberg]

That could be an interesting other exploration! I haven't dug too much into the new languages designs for ESLint core or how they compare/contrast with jsonc-eslint-parser. I don't have time to investigate them for this package anytime soon, but if someone wants to file an issue that could be good separate from this one.

[rubiesonthesky]

Publint is also a tool for linting package.json kinda. I recently listed [1] some files that would be useful if it would recognise as a files that should not be included in npm package. The difference with that tool to this eslint plugin is that it lints the published version while this eslint plugin is used before packing / publishing. Correct me if I’m wrong here :)

I’m not sure how many of these files would be listed in files section and how many this plugin could detect, but maybe some of them are valid also for this eslint plugin and no-redudant-files rule.

[1] publint/publint#141

[michaelfaith]

My sense is that when people include those files in published packages it's because they're not explicitly declaring files in their package.json. So having a process to lint published packages like they're doing can catch those cases. A plugin doing static analysis on the package.json wouldn't really be able to detect cases where packages include more than they should, other than just recommending using files generally. I mean we could certainly check files for a set of files that shouldn't be included like a jest.config.ts file, but I don't think that's the reason those files end up in packages to begin with. You know what I mean?

[rubiesonthesky]

Yeah, I agree. How they may end up in the package is that the glob given in files includes those files accidentally. For example including all files in src and there is some special eslint config for certain directory. I'm not sure how no-redundant-files does its check. If it's just checking the files list as a string, I don't think it would detect any accidents mentioned. But if it is going through the actual files included in the files and checking their filenames then it could be helpful.

There is also possibility that some of those files are by purpose included. For example, if it's template project.

Fun fact with the file list that i gathered is that they are all files that I found in popular npm packages. The eslint files may be on purpose because some people like to run eslint on published package and they want to ship their config with the package for that reason. All the other files are probably accidents. (And most of them where probably old packages that haven't been updated in 5 years.)