-
Notifications
You must be signed in to change notification settings - Fork 539
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
Unused dependency checker and fixer #23989
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you generate a PR from cleanup in client? Will be very helpful to see what we are getting with this policy.
build-tools/packages/build-cli/src/library/repoPolicyCheck/npmPackages.ts
Outdated
Show resolved
Hide resolved
build-tools/packages/build-cli/src/library/repoPolicyCheck/npmPackages.ts
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for putting this together! In #22448 (comment) I outlined three options for this type of check. This PR is option 2, and I got curious about option 1, which is doing a per-package integration at the task level - adding new depcheck tasks to individual packages and then running them as part of the build.
I looked into depcheck's config story, and there is no inheritance or looking up the tree for configs. It's pretty clearly a "one package at a time" tool. However, we can create our own base config and import it and modify it on a per-package basis since the config supports CJS. So the next question is, "can we share a config that the majority of packages would use?"
The answer to that is a little unclear, but based on my testing, it doesn't look good unfortunately. The problem is that there are a lot of false results. Depcheck flags some deps that are used at runtime or in CI, etc. I suspect each package in the repo will need some level of config. That means a config file in each package, even if it mostly inherits from the root config. I suspect many packages will have additional exclusions that apply only to it as well.
These false positives also make it unlikely that an autofixer will be safe. Each removal needs to be scrutinized.
All of this together points towards option 1 possibly being a better approach for this integration. I explored those changes in #23992. Note that many of those changes would be needed with this approach as well, since each package will need its own config.
build-tools/packages/build-cli/src/library/repoPolicyCheck/npmPackages.ts
Outdated
Show resolved
Hide resolved
@tylerbutler / @jason-ha - Thanks for reviewing the first pass of the implementation. Requesting a re-review. Please let me know if we can make further improvements to our approach. Thanks! |
@@ -43,6 +43,8 @@ | |||
"build:test:esm": "tsc --project ./src/test/tsconfig.json", | |||
"check:biome": "biome check .", | |||
"check:format": "npm run check:biome", | |||
"check:knip": "knip --no-config-hints", | |||
"knip:fix": "knip --fix --fix-type dependencies --no-config-hints", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
--no-config-hints
-- supresses the hints provided by knip tool to remove the unused ignoreDependencies
coming from knip.base.config.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's mildly annoying the fix-types aren't part of config. DOesn't seem to be supported.
// Import the shared config from the root of the repo. | ||
import sharedConfig from "../../../knip.base.ts"; | ||
|
||
export default { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add a doc comment with a type directive here so we can get type checking on the config object. Something like this:
/**
* @type {import("knip").Config}
*/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh right it's typescript - just import type
then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And you can remove the ts-check-related comments.
import sharedConfig from "../../../knip.base.ts"; | ||
|
||
export default { | ||
include: [...sharedConfig.include], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
include: [...sharedConfig.include], | |
...sharedConfig, |
"@andrewbranch/untar.js": "^1.0.3", | ||
"@fluid-tools/build-infrastructure": "workspace:~", | ||
"@fluid-tools/version-tools": "workspace:~", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is definitely a false positive. Does it understand the workspace:~
deps?
"@fluidframework/bundle-size-tools": "workspace:~", | ||
"@inquirer/prompts": "^7.0.1", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Likely a false positive.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think most of the removed deps are actually used.
Purpose: Report and fix unused dependencies.
check:knip
to check andknip:fix
to fix, the unused dependencies found in the package.json of any the packages in the repo . The underlying tool used isknip
npm package.build-cli
. The idea is to incrementally make the same change to all the packages in our repo, to ensure quicker PR turnaround time and to open up possibility of multiplying the effort with more devs.Future of this work
Context
(This work is continuation of the previous hack project #22448 and also the work done by Tyler in the PR here: #23992 where we explore the various build/reporting options that work the best with our requirements.)