2 Commits (e22a67c432d18fa9647cdfd7b936fce4b7cb39e5)

Author	SHA1	Message	Date
ottomated	11985c020f	docs: desloppify browser support page (#18333) ... The text in https://svelte.dev/docs/svelte/browser-support is quite redundant and has a lot of AI smell. I did my best to make it more concise and remove some slop comments in the generation script. Requires a companion PR in svelte.dev: https://github.com/sveltejs/svelte.dev/pull/2013 <img width="620" height="809" alt="image" src="https://github.com/user-attachments/assets/7be9d5ff-1623-4897-a2d4-9a601b20f54d" /> ### Before submitting the PR, please make sure you do the following - [ ] It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs - [x] Prefix your PR title with `feat:`, `fix:`, `chore:`, or `docs:`. - [x] This message body should clearly illustrate what problems it solves. - [ ] Ideally, include a test that fails without this PR but passes with it. - [x] If this PR changes code within `packages/svelte/src`, add a changeset (`npx changeset`). ### Tests and linting - [x] Run the tests with `pnpm test` and lint the project with `pnpm lint` --------- Co-authored-by: Rich Harris <rich.harris@vercel.com>	5 months ago
Mathias Picker	27e74c4df7	docs: add auto-generated browser support page (#18276) ... ## Summary Adds a [Browser support](https://github.com/MathiasWP/svelte/blob/document-pipeline-draft/documentation/docs/07-misc/05-browser-support.md) page listing the minimum browser versions Svelte's runtime and compiler output require. The page (headline floor + per-feature requirements) is auto-generated by `packages/svelte/scripts/generate-browser-support.js`, which scans the code Svelte actually ships against the [web-features](https://github.com/web-platform-dx/web-features) Baseline dataset and resolves results to concrete browser versions via [baseline-browser-mapping](https://github.com/web-platform-dx/baseline-browser-mapping). CI fails if a PR moves the floor without regenerating the page. For 5.55.9 the floor is **Baseline 2020**: Chrome/Edge 87, Firefox 83, Safari 14. ## How it works 1. **Headline floor.** Each runtime entry from `pkg.exports` is bundled with rollup using production conditions, then walked with TypeScript's compiler API + TypeChecker. The walker (`browser-support.detector.js`) flags any web-features ID the runtime references; the highest Baseline year among them is the floor. 2. **Per-feature requirements.** Every user-facing surface is enumerated programmatically — every `bind:*` from `binding_properties`, every public subpackage export discovered via `pkg.exports` + `import * as ns`, every rune from `RUNES`, and directives (`transition:` / `animate:` / `use:` / `@attach` / `{@html}` / custom elements). Each gets a fixture, compiled and bundled like user code, then scanned. A row appears only when the fixture's floor exceeds the runtime floor. 3. **Supplemental rules.** A handful of APIs `web-features` doesn't catalogue (`getComputedStyle(...).zoom`, `box: 'device-pixel-content-box'`) are detected with the same type-aware walker via a small `register_extra_rules` list with inline justifications. 4. **Ignore sets.** `SAFE_TO_IGNORE` covers dataset bugs and feature-detected APIs with graceful fallbacks. `BEHAVIORAL_IGNORE` hides APIs reached only via specific user code from the headline (they still surface as conditional rows); staleness-checked, so CI fails if an entry no longer exists in the runtime. Resolves #18198. Provides an answer to the long-standing #558. ## Test plan - [ ] \`pnpm --filter svelte generate:browser-support\` regenerates the page idempotently - [ ] CI fails when a code change bumps the floor without regenerating the page - [ ] Page renders correctly on svelte.dev 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Co-authored-by: Rich Harris <rich.harris@vercel.com>	5 months ago