Three changes that came out of the 1.1.0 consumer review and #15, all deliberately left out of 1.2.0 because each is semver-major. Filing together so they don't get lost.
1. Default navigation.showControls to steps.length > 1
DEFAULT_NAVIGATION.showControls is false while showClose is true, so a two-step tour renders one close button and no way to reach step 2. totalSteps correctly reports 2.
useTour is headless-first by design and its own JSDoc shows the consumer rendering their own Back/Next, so the default isn't wrong — but it is the last remaining dead end now that #15 makes the built-in buttons keyboard-operable. A single-step tour genuinely doesn't need controls; a multi-step one is broken without them unless you supply your own.
Why it can't be a minor: every consumer who renders their own controls today would suddenly get a duplicate set — a silent visual regression.
Mitigated for now by documenting it: #15 updates the README and Flows.mdx to show navigation: { showControls: true } in the primary example alongside the headless form.
2. Remove enableHelper
Typed in TipMagicOptions, defaulted to true in DEFAULT_OPTIONS, and never read by a single line of code — confirmed in both source and the published bundle, where the identifier appears exactly once.
There is nothing left for it to gate: TipAdvisor is opt-in by rendering <TipAdvisor />, and the flow helper API is driven by useTour. Worse than a surprising default, a dead option makes a careful reader infer behaviour that isn't there — a reviewer reported it as "mounting the provider installs a global F1 overlay", which it does not.
Marked @deprecated in #15; remove the property at 2.0.
3. Decide respectReducedMotion
Was also dead before #15 — declared, defaulted to true, documented across four Storybook pages, never read. #15 implements it: the provider sets data-tip-magic-motion="always" on the tooltip when it is false, and the stylesheet's prefers-reduced-motion guards exclude that attribute.
That covers everything the tour and tooltip animate, since both render inside .tip-magic-tooltip. It does not cover tip-advisor.css, which has its own unconditional reduced-motion block. Either extend the opt-out to TipAdvisor or narrow the option's documented scope. If neither happens, remove the option instead of shipping one that only half-applies.
Context: #15 (tour lifecycle, elevation, accessibility, step types) and #16 (CSS packaging).
Three changes that came out of the 1.1.0 consumer review and #15, all deliberately left out of 1.2.0 because each is semver-major. Filing together so they don't get lost.
1. Default
navigation.showControlstosteps.length > 1DEFAULT_NAVIGATION.showControlsisfalsewhileshowCloseistrue, so a two-step tour renders one close button and no way to reach step 2.totalStepscorrectly reports 2.useTouris headless-first by design and its own JSDoc shows the consumer rendering their own Back/Next, so the default isn't wrong — but it is the last remaining dead end now that #15 makes the built-in buttons keyboard-operable. A single-step tour genuinely doesn't need controls; a multi-step one is broken without them unless you supply your own.Why it can't be a minor: every consumer who renders their own controls today would suddenly get a duplicate set — a silent visual regression.
Mitigated for now by documenting it: #15 updates the README and
Flows.mdxto shownavigation: { showControls: true }in the primary example alongside the headless form.2. Remove
enableHelperTyped in
TipMagicOptions, defaulted totrueinDEFAULT_OPTIONS, and never read by a single line of code — confirmed in both source and the published bundle, where the identifier appears exactly once.There is nothing left for it to gate:
TipAdvisoris opt-in by rendering<TipAdvisor />, and the flow helper API is driven byuseTour. Worse than a surprising default, a dead option makes a careful reader infer behaviour that isn't there — a reviewer reported it as "mounting the provider installs a global F1 overlay", which it does not.Marked
@deprecatedin #15; remove the property at 2.0.3. Decide
respectReducedMotionWas also dead before #15 — declared, defaulted to
true, documented across four Storybook pages, never read. #15 implements it: the provider setsdata-tip-magic-motion="always"on the tooltip when it isfalse, and the stylesheet'sprefers-reduced-motionguards exclude that attribute.That covers everything the tour and tooltip animate, since both render inside
.tip-magic-tooltip. It does not covertip-advisor.css, which has its own unconditional reduced-motion block. Either extend the opt-out toTipAdvisoror narrow the option's documented scope. If neither happens, remove the option instead of shipping one that only half-applies.Context: #15 (tour lifecycle, elevation, accessibility, step types) and #16 (CSS packaging).