Decluttering Client Repos

Table of Contents

• Knip
  • Setup
  • Analyzing a repo
  • Example of false positives on unused exports
  • Example of reported duplicated exports not actually causing a problem
  • Example of false positive on unused dependencies
• Applying package changes while keeping local installs clean and consistent

Knip

Knip is useful towards identifying unlisted dependencies, duplicated exports, and potential unused files, dependencies or exports.

Watch out for false positives!

Avoid blindly implementing everything reported. Look, verify, and test. Do your own searches and thinking for things like reported unused exports.

Knip is not meant for resource-core, webfonts-core, pankosmia-web, or desktop-app-*.

It is for projects constructed with a packages.json and an index.js, which it uses to step through and evaluate all includes in the app.

Setup

npm install -g knip or npm install --global knip (to install or update)

Analyzing a repo

In the root of the client repo in a terminal, enter knip. It will provide a list of any of any unused, unlisted, or duplicated things that it suspects it has found.

Example of false positives on unused exports

It will report Selection.styles.jsx as an unused export (because of the filename) even when it is in use. Be careful to not remove this file where its export is actually in use.

Example of reported duplicated exports not actually causing a problem

Selection.styles.jsx is exporting sx, which works fine as used.

Example of false positive on unused dependencies

Knip is quite good at following the include chain throughout a project. However, sometimes dependencies are in place outside of this chain, which it will miss. For example, if a package.json includes use of react-scripts in its scripts section, it’s dependency chain includes babel which includes a devDependency of @babel/plugin-proposal-private-property-in-object. Knip will miss that case and report that as an unused dependency, but in that case it is actually used.

Applying package changes while keeping local installs clean and consistent

Migration from npm to pnpm in process

Use the repo root lock file to determine which applies: pnpm-lock.yaml → pnpm; package-lock.json → npm. For additional detail see our Migration Plan.

	pnpm-lock.yaml	package-lock.json
Use	pnpm install or manually edit package.json then run pnpm i	npm ci. This removes node_modules and matches the lock file.
To bump a package version follow pnpm i/npm ci with:	pnpm i <package_name>@0.1.29 --save-exact or manually edit package.json then run pnpm i	npm i <package_name>@0.1.29 --save-exact
To remove a package follow npm ci with:	pnpm uninstall <package_name> or manually edit package.json then run pnpm i	npm uninstall <package_name>
To add a package follow pnpm i/npm ci with:	pnpm i <package_name> --save-dev or pnpm i <package_name> -D (for devDependencies) or pnpm add <package-name> -O or manually edit package.json then run pnpm i	npm i <package_name> --save-dev or npm i <package_name> -D (for devDependencies) or npm i <package-name> --save-optional