feat: align with scrollIntoView, and modernize the toolchain - #1
Merged
Merged
Conversation
Alignment now follows Element.scrollIntoView instead of approximating it. "start" and "end" are logical, so on the x axis they resolve against the container's direction and swap sides in an RTL container. The container's scroll-padding and the target's scroll-margin are both honoured, and alignment is measured against the scrollport rather than the border box. Two changes need attention when upgrading: - The `offset` option is gone, replaced by the container's scroll-padding. One number could not describe two axes — aligning both at once applied the same inset horizontally and vertically — nor a header and a footer of different heights. `offset: 80` becomes `scroll-padding-top: 80px` on the container. - "start" and "end" swap sides in RTL containers, where they now mean what the platform means by them. Left-to-right containers are unaffected. Found while reviewing, and fixed here: - Alignment measured the border box rather than the scrollport, so a border pushed the target underneath itself, "nearest" judged a target hidden by the border to be visible and refused to scroll, and a vertical scrollbar shifted every horizontal alignment by its own width. The last of those affects most scrollable containers. The scrollport is now read from clientTop/clientLeft and clientHeight/clientWidth. - scroll-padding values that together exceed the scrollport left an inverted region, in which every target counted as too large to fit and "nearest" moved even a plainly visible one. They are reduced proportionally now. - The exports map resolved ESM type declarations for CJS consumers: the `types` condition sat above `require`, so the nested `require.types` was never reached and require() got .d.ts types for a .cjs implementation. - The Quick Start example in the README did not type-check. The toolchain moves to match easing-scroll: tsdown in place of tsup, publint and are-the-types-wrong on every build, vitest coverage held at a 100% threshold, Prettier, CI on every pull request across Node 22 and 24, and publishing from GitHub Actions over OIDC instead of from a developer machine. The example is a workspace member that depends on the package via workspace:*, so its type check exercises the exports map the way a published consumer would. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
The matrix exercised the toolchain twice over, not the library: the published bundle is browser code with no Node API in it, and the suite runs in jsdom, so neither varies by Node version. What is left is picking the one version worth running, and 22 is both the floor the toolchain leaves — tsdown wants ^22.18.0 || >=24.11.0, jsdom ^22.22.2 || ^24.15.0 || >=26.0.0 — and the version release.yml publishes from, so CI now matches what actually ships. With the matrix gone the job needs no explicit name; it reports as `check`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This branch was successfully deployed
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.
Alignment now follows Element.scrollIntoView instead of approximating it. "start" and "end" are logical, so on the x axis they resolve against the container's direction and swap sides in an RTL container. The container's scroll-padding and the target's scroll-margin are both honoured, and alignment is measured against the scrollport rather than the border box.
Two changes need attention when upgrading:
offsetoption is gone, replaced by the container's scroll-padding. One number could not describe two axes — aligning both at once applied the same inset horizontally and vertically — nor a header and a footer of different heights.offset: 80becomesscroll-padding-top: 80pxon the container.Found while reviewing, and fixed here:
typescondition sat aboverequire, so the nestedrequire.typeswas never reached and require() got .d.ts types for a .cjs implementation.The toolchain moves to match easing-scroll: tsdown in place of tsup, publint and are-the-types-wrong on every build, vitest coverage held at a 100% threshold, Prettier, CI on every pull request across Node 22 and 24, and publishing from GitHub Actions over OIDC instead of from a developer machine. The example is a workspace member that depends on the package via workspace:*, so its type check exercises the exports map the way a published consumer would.