prop-flow: detect props that are always passed the same value - #936
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
prop-flow now reports props that are passed the same value at every call site. Constancy is orthogonal to whether an optional prop's
?earns its keep — a prop can bejustifiedand still be constant everywhere it is passed — so it lands as its own field onPropAnalysisrather than as a sixth verdict. Values are read off the type, not the syntax, sosize="sm", aconst, an enum member and a property of anas constobject all resolve to one value, and a single unreadable site leaves the claim unmade.Changes
constantfield ({ coverage, value }) on everyPropAnalysis,nullwhere there is no finding.coverage: 'passes'means the passing sites agree;'all'means the omissions land on the value too via the component's own binding default — the case where the prop can go away entirely. Nothing is reported below two passing sites.values.tsresolves values throughchecker.getTypeAtLocationplus the literal-type checks, covering string/number/boolean literals, boolean shorthand (<C dense />istrue), enum members andas constproperties. Amanualsite or any type the checker cannot pin to a single literal suppresses the finding.--all-propswidens discovery to required props, not the report: a required prop appears only when it carries a constant value, under a newrequiredverdict. Without the flag the output is byte-identical to before.caller-dead. Each absorbed omission is listed as arealsite at the call site where the default fires, so the counts still line up with the sites below.indexProgram, JSX tag resolution, the symbol-id allocator) moved out ofanalyzer.tsinto acreateUsageIndexmodule, which is what lets it be tested directly.--all-propsrow and the absorbed-default example; CHANGELOG cut to 2.0.0 and the version bumped.Breaking changes in the library API and the
--jsonshape (the CLI arguments and the text output only gained things):OptionalPropis nowDeclaredProp, with an addedoptionalfieldAnalyzer.listOptionalPropsis nowlistProps(component, { includeRequired })PropAnalysis.constantis required, so every--jsonrow carries itRelated issues
Closes #934