fix(lint): recognize gsap.fromTo initial state in overlay-visibility check#2088
Open
miguel-heygen wants to merge 1 commit into
Open
fix(lint): recognize gsap.fromTo initial state in overlay-visibility check#2088miguel-heygen wants to merge 1 commit into
miguel-heygen wants to merge 1 commit into
Conversation
…check
gsap_fullscreen_overlay_starts_visible only looked at a tween's destination
values (toVars) when deciding whether an element starts hidden at t=0. For
a fromTo() call this destination is the wrong state to check — a
fromTo(el, {opacity:0}, {opacity:1}, 0) fade-in genuinely starts hidden,
but its propertyValues only captured opacity:1, so the rule treated it as
starting visible. This misfired specifically when the element was later
hidden again (e.g. an outro fade), since a guard that otherwise suppressed
bare fromTo entrances no longer applied once a later hide was detected.
Thread the parser's existing fromProperties (fromTo's "from" vars, already
parsed but previously unused by this rule) onto GsapWindow as
fromPropertyValues, and prefer it over propertyValues when checking a
window's start state.
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
1 participant
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.
What
gsap_fullscreen_overlay_starts_visiblefalse-positives on a full-frame overlay that fades in viagsap.fromTo(el, {opacity:0}, {opacity:1}, 0)at t=0, when that element is later hidden again (e.g. an outro fade or a hard-killtl.set). The overlay genuinely starts hidden, but the rule flags it as starting visible and asks the author to redundantly addopacity: 0in CSS on top of the fromTo call.Why
GsapWindow.propertyValuesis populated fromanimation.properties, which for afromTo(el, fromVars, toVars, pos)call only reflectstoVars— the destination state, not the starting state. The rule'sstartsHiddenAtZerocheck inspectedpropertyValuesat position 0, so for a fade-in fromTo it saw the destination (opacity: 1) instead of the true t=0 state (opacity: 0), and never recognized it as "starts hidden." The parser already parsesfromVarsseparately intoanimation.fromProperties, butGsapWindowhad no field for it and nothing read it.The misfire was conditional: a bare fromTo fade-in with nothing else hiding the element later didn't trigger the rule (a separate guard suppressed it), but it did trigger once the element was hidden again later in the timeline.
How
fromPropertyValuesfield toGsapWindow, populated fromanimation.fromPropertiesinextractGsapWindows.windowStartStateValueshelper that returnsfromPropertyValuesforfromTowindows (falling back topropertyValuesif absent) andpropertyValuesotherwise.startsHiddenAtZeroto check the window's true start state instead of always checking the destination.makesOverlayVisible/isSceneBoundaryExitchecks for the same blind spot — they intentionally use the destination state (correct for "does this tween end in a visible/hidden state"), so no change was needed there.Test plan
fromTofade-in at t=0 (no finding), and the regression case —fromTofade-in at t=0 plus a later hide (previously flagged, now correctly not flagged).bun run testinpackages/lint— all 349 tests pass, no regressions.bun run typecheckinpackages/lint— clean.oxlint/oxfmt --checkon changed files — clean.