{"owner":"sveltejs","repo":"svelte","hasSkills":true,"totalSkillsCount":5,"totalTokensCount":2290,"categories":["anthropic-skill","root-instruction","plugin-manifest","cursor-rule"],"hasMcp":false,"mcpConfig":null,"found":[".agents/skills/performance-investigation/SKILL.md","AGENTS.md","packages/svelte/README.md","packages/svelte/tests/README.md",".cursorrules (svelte.mdc)"],"skills":{".agents/skills/performance-investigation/SKILL.md":"---\nname: performance-investigation\ndescription: Investigate performance regressions and find opportunities for optimization\n---\n\n## Quick start\n\n1. Start from a branch you want to measure (for example `foo`).\n2. Run:\n\n```sh\npnpm bench:compare main foo\n```\n\nIf you pass one branch, `bench:compare` automatically compares it to `main`.\n\n## Where outputs go\n\n- Summary report: `benchmarking/compare/.results/report.txt`\n- Raw benchmark numbers:\n  - `benchmarking/compare/.results/main.json`\n  - `benchmarking/compare/.results/<your-branch>.json`\n- CPU profiles (per benchmark, per branch):\n  - `benchmarking/compare/.profiles/main/*.cpuprofile`\n  - `benchmarking/compare/.profiles/main/*.md`\n  - `benchmarking/compare/.profiles/<your-branch>/*.cpuprofile`\n  - `benchmarking/compare/.profiles/<your-branch>/*.md`\n\nThe `.md` files are generated summaries of the CPU profile and are usually the fastest way to inspect hotspots.\n\n## Suggested investigation flow\n\n1. Open `benchmarking/compare/.results/report.txt` and identify largest regressions first.\n2. For each high-delta benchmark, compare:\n   - `benchmarking/compare/.profiles/main/<benchmark>.md`\n   - `benchmarking/compare/.profiles/<branch>/<benchmark>.md`\n3. Look for changes in self/inclusive hotspot share in runtime internals (`runtime.js`, `reactivity/batch.js`, `reactivity/deriveds.js`, `reactivity/sources.js`).\n4. Make one optimization change at a time, then re-run targeted benches before re-running full compare.\n\n## Fast benchmark loops\n\nRun only selected reactivity benchmarks by substring:\n\n```sh\npnpm bench kairo_mux kairo_deep kairo_broad kairo_triangle\npnpm bench repeated_deps sbench_create_signals mol_owned\n```\n\n## Tests to run after perf changes\n\nRuntime reactivity regressions are most likely in runes runtime tests:\n\n```sh\npnpm test runtime-runes\n```\n\n## Helpful script\n\nFor quick cpuprofile hotspot deltas between two branches:\n\n```sh\nnode benchmarking/compare/profile-diff.mjs kairo_mux_owned main foo\n```\n\nThis prints top function sample-share deltas for the selected benchmark.\n\n## Practical gotchas\n\n- `bench:compare` checks out branches while running. Avoid uncommitted changes (or stash them) so branch switching is safe.\n- Each `bench:compare` run rewrites `benchmarking/compare/.results` and `benchmarking/compare/.profiles`.\n","AGENTS.md":"# Svelte Coding Agent Guide\n\nThis guide is for AI coding agents working in the Svelte monorepo.\n\n**Important:** Read and follow [`CONTRIBUTING.md`](./CONTRIBUTING.md) as well - it contains essential information about testing, code structure, and contribution guidelines that applies here.\n\nWhen submitting a PR, you **MUST** read [`PULL_REQUEST_TEMPLATE.md`](./.github/PULL_REQUEST_TEMPLATE.md) and fill it out correctly. **DO NOT** submit a PR without running the full test suite.\n\n## Security Policy\n\nSee https://github.com/sveltejs/svelte/security/policy.\n\n## Quick Reference\n\nIf asked to do a performance investigation, use the `performance-investigation` skill.\n","packages/svelte/README.md":"<a href=\"https://svelte.dev\">\n\t<picture>\n\t\t<source media=\"(prefers-color-scheme: dark)\" srcset=\"../../assets/banner_dark.png\">\n\t\t<img src=\"../../assets/banner.png\" alt=\"Svelte - web development for the rest of us\" />\n\t</picture>\n</a>\n\n[![npm version](https://img.shields.io/npm/v/svelte.svg)](https://www.npmjs.com/package/svelte) [![license](https://img.shields.io/npm/l/svelte.svg)](LICENSE.md) [![Chat](https://img.shields.io/discord/457912077277855764?label=chat&logo=discord)](https://svelte.dev/chat)\n\n## What is Svelte?\n\nSvelte is a new way to build web applications. It's a compiler that takes your declarative components and converts them into efficient JavaScript that surgically updates the DOM.\n\nLearn more at the [Svelte website](https://svelte.dev), or stop by the [Discord chatroom](https://svelte.dev/chat).\n\n## Getting started\n\nYou can play around with Svelte in the [tutorial](https://svelte.dev/tutorial), [examples](https://svelte.dev/examples), and [REPL](https://svelte.dev/repl).\n\nWhen you're ready to build a full-fledge application, we recommend using [SvelteKit](https://svelte.dev/docs/kit):\n\n```sh\nnpx sv create my-app\ncd my-app\nnpm install\nnpm run dev\n```\n\nSee [the SvelteKit documentation](https://svelte.dev/docs/kit) to learn more.\n\n## Changelog\n\n[The Changelog for this package is available on GitHub](https://github.com/sveltejs/svelte/blob/main/packages/svelte/CHANGELOG.md).\n\n## Supporting Svelte\n\nSvelte is an MIT-licensed open source project with its ongoing development made possible entirely by fantastic volunteers. If you'd like to support their efforts, please consider:\n\n- [Becoming a backer on Open Collective](https://opencollective.com/svelte).\n\nFunds donated via Open Collective will be used for compensating expenses related to Svelte's development.\n","packages/svelte/tests/README.md":"# Test repo\n\nThis repo tries to migrate as many tests from the current Svelte project over to test against the new compiler/runtime.\n\n## Differences to the old test suite\n\n- `compiler` options are different currently, a wrapper function in `helpers.js` was added and call sites rerouted to that\n- regex in the loader was adjusted, a `$` was added to the `import * as ..` regex (because the new runtime does `import * as $ from ..` for the runtime)\n- `vitest.config.js` was altered: `resolve-svelte` plugin also aliases `svelte` (the current runtime import) and `test.dir` was adjusted because the monorepo structure is different (compiler/runtime are separate packages here currently)\n- new runtime does not expose things like raf etc, which were used in some tests (runtime for example; for transition/animation tests). These are commented out for now\n- when changing an attribute, the JSDOM does not reflect the value immediately anymore because the runtime does update the DOM in after a tick, not synchronously - this results in many tests needing additional `await Promise.resolve()` lines\n\n## Breaking changes\n\n- Order of list insertions has changed: It's now back to front because that's faster\n- Slight timing differences mean that things may fire less in some cases (behavior should be unaffected though) - see `component-binding-each-remount-unkeyed` for an example\n- It's currently possible to create infinite loops with `$:` invoking each other\n- Fallback value is now set on all `undefined` values, not just on the first one\n- CSS is no longer minified. Unused styles are instead commented out\n- `:global(...)` compound selectors (e.g. `.foo:global(.bar)` or `:global(.foo).bar`) are no longer permitted. These are nonsensical and don't do anything useful in Svelte 4 — better to just get rid of them\n- transitions: when one element fades out and a new one (which is on the same element but another instance of it) fades in at the same time, the new one is now below the old one (was above before)\n- transitions: now wait one tick before they start playing to align with web animations API\n\n## TODOs\n\n- the new runtime does not expose named exports such as `svelte/store` yet, so can't test those\n- event `this` context is not preserved due to event delegation etc. Problem? Or necessary/ok breaking change?\n- order of operations should be preserved: first all attribute setters (spread props, static props) in order, then mutation directives (actions, bindings) in order, then style/class directives in order\n\n## Tests that succeeded but need a closer look\n\n- `$$slot` was modified to succeed, see TODOs inside for more info\n- `await-component-oncreate` needs to `await Promise.resolve()` because `onMount` runs async, too. Is this ok?\n- `component-slot-fallback-2` has one check commented out, because store subscriptions are deduplicated at the runtime level now. Should this be seen as a breaking change? If yes, ok?\n\n## Tests that are not copied over yet\n\n- everything except runtime is missing so far\n- animation tests within runtime folder were not copied over\n- `beforeUpdate`/`afterUpdate` tests\n",".cursorrules (svelte.mdc)":"---\ndescription: \"Svelte best practices and patterns for modern web applications\"\nglobs: **/*.svelte, src/**/*.ts, src/**/*.js\nalwaysApply: false\n---\n# Svelte Best Practices\n\n## Component Structure\n- Keep components small and focused\n- Use proper TypeScript integration\n- Implement proper props typing\n- Use proper event dispatching\n- Keep markup clean and readable\n- Use proper slot implementation\n\n## Reactivity\n- Use proper reactive declarations\n- Implement proper stores\n- Use proper reactive statements\n- Handle derived values properly\n- Use proper lifecycle functions\n- Implement proper bindings\n\n## State Management\n- Use proper Svelte stores\n- Keep stores modular\n- Use proper derived stores\n- Implement proper actions\n- Handle async state properly\n- Use proper store subscriptions\n\n## Performance\n- Use proper component lazy loading\n- Implement proper transitions\n- Use proper animations\n- Avoid unnecessary reactivity\n- Use proper event forwarding\n- Implement proper key blocks\n\n## Routing\n- Use SvelteKit for routing\n- Implement proper layouts\n- Use proper route parameters\n- Handle loading states properly\n- Implement proper error pages\n- Use proper navigation methods\n\n## Forms\n- Use proper form bindings\n- Implement proper validation\n- Handle form submission properly\n- Show proper loading states\n- Use proper error handling\n- Implement proper form reset\n\n## TypeScript Integration\n- Use proper component types\n- Implement proper prop types\n- Use proper event types\n- Handle proper type inference\n- Use proper store types\n- Implement proper action types\n\n## Testing\n- Write proper unit tests\n- Implement proper component tests\n- Use proper testing libraries\n- Test stores properly\n- Implement proper mocking\n- Test async operations\n\n## Best Practices\n- Follow Svelte style guide\n- Use proper naming conventions\n- Keep components organized\n- Implement proper error handling\n- Use proper event handling\n- Document complex logic\n\n## Build and Tooling\n- Use Vite for development\n- Configure proper build setup\n- Use proper environment variables\n- Implement proper code splitting\n- Use proper asset handling\n- Configure proper optimization\n"},"files":{".agents/skills/performance-investigation/SKILL.md":"---\nname: performance-investigation\ndescription: Investigate performance regressions and find opportunities for optimization\n---\n\n## Quick start\n\n1. Start from a branch you want to measure (for example `foo`).\n2. Run:\n\n```sh\npnpm bench:compare main foo\n```\n\nIf you pass one branch, `bench:compare` automatically compares it to `main`.\n\n## Where outputs go\n\n- Summary report: `benchmarking/compare/.results/report.txt`\n- Raw benchmark numbers:\n  - `benchmarking/compare/.results/main.json`\n  - `benchmarking/compare/.results/<your-branch>.json`\n- CPU profiles (per benchmark, per branch):\n  - `benchmarking/compare/.profiles/main/*.cpuprofile`\n  - `benchmarking/compare/.profiles/main/*.md`\n  - `benchmarking/compare/.profiles/<your-branch>/*.cpuprofile`\n  - `benchmarking/compare/.profiles/<your-branch>/*.md`\n\nThe `.md` files are generated summaries of the CPU profile and are usually the fastest way to inspect hotspots.\n\n## Suggested investigation flow\n\n1. Open `benchmarking/compare/.results/report.txt` and identify largest regressions first.\n2. For each high-delta benchmark, compare:\n   - `benchmarking/compare/.profiles/main/<benchmark>.md`\n   - `benchmarking/compare/.profiles/<branch>/<benchmark>.md`\n3. Look for changes in self/inclusive hotspot share in runtime internals (`runtime.js`, `reactivity/batch.js`, `reactivity/deriveds.js`, `reactivity/sources.js`).\n4. Make one optimization change at a time, then re-run targeted benches before re-running full compare.\n\n## Fast benchmark loops\n\nRun only selected reactivity benchmarks by substring:\n\n```sh\npnpm bench kairo_mux kairo_deep kairo_broad kairo_triangle\npnpm bench repeated_deps sbench_create_signals mol_owned\n```\n\n## Tests to run after perf changes\n\nRuntime reactivity regressions are most likely in runes runtime tests:\n\n```sh\npnpm test runtime-runes\n```\n\n## Helpful script\n\nFor quick cpuprofile hotspot deltas between two branches:\n\n```sh\nnode benchmarking/compare/profile-diff.mjs kairo_mux_owned main foo\n```\n\nThis prints top function sample-share deltas for the selected benchmark.\n\n## Practical gotchas\n\n- `bench:compare` checks out branches while running. Avoid uncommitted changes (or stash them) so branch switching is safe.\n- Each `bench:compare` run rewrites `benchmarking/compare/.results` and `benchmarking/compare/.profiles`.\n","AGENTS.md":"# Svelte Coding Agent Guide\n\nThis guide is for AI coding agents working in the Svelte monorepo.\n\n**Important:** Read and follow [`CONTRIBUTING.md`](./CONTRIBUTING.md) as well - it contains essential information about testing, code structure, and contribution guidelines that applies here.\n\nWhen submitting a PR, you **MUST** read [`PULL_REQUEST_TEMPLATE.md`](./.github/PULL_REQUEST_TEMPLATE.md) and fill it out correctly. **DO NOT** submit a PR without running the full test suite.\n\n## Security Policy\n\nSee https://github.com/sveltejs/svelte/security/policy.\n\n## Quick Reference\n\nIf asked to do a performance investigation, use the `performance-investigation` skill.\n","packages/svelte/README.md":"<a href=\"https://svelte.dev\">\n\t<picture>\n\t\t<source media=\"(prefers-color-scheme: dark)\" srcset=\"../../assets/banner_dark.png\">\n\t\t<img src=\"../../assets/banner.png\" alt=\"Svelte - web development for the rest of us\" />\n\t</picture>\n</a>\n\n[![npm version](https://img.shields.io/npm/v/svelte.svg)](https://www.npmjs.com/package/svelte) [![license](https://img.shields.io/npm/l/svelte.svg)](LICENSE.md) [![Chat](https://img.shields.io/discord/457912077277855764?label=chat&logo=discord)](https://svelte.dev/chat)\n\n## What is Svelte?\n\nSvelte is a new way to build web applications. It's a compiler that takes your declarative components and converts them into efficient JavaScript that surgically updates the DOM.\n\nLearn more at the [Svelte website](https://svelte.dev), or stop by the [Discord chatroom](https://svelte.dev/chat).\n\n## Getting started\n\nYou can play around with Svelte in the [tutorial](https://svelte.dev/tutorial), [examples](https://svelte.dev/examples), and [REPL](https://svelte.dev/repl).\n\nWhen you're ready to build a full-fledge application, we recommend using [SvelteKit](https://svelte.dev/docs/kit):\n\n```sh\nnpx sv create my-app\ncd my-app\nnpm install\nnpm run dev\n```\n\nSee [the SvelteKit documentation](https://svelte.dev/docs/kit) to learn more.\n\n## Changelog\n\n[The Changelog for this package is available on GitHub](https://github.com/sveltejs/svelte/blob/main/packages/svelte/CHANGELOG.md).\n\n## Supporting Svelte\n\nSvelte is an MIT-licensed open source project with its ongoing development made possible entirely by fantastic volunteers. If you'd like to support their efforts, please consider:\n\n- [Becoming a backer on Open Collective](https://opencollective.com/svelte).\n\nFunds donated via Open Collective will be used for compensating expenses related to Svelte's development.\n","packages/svelte/tests/README.md":"# Test repo\n\nThis repo tries to migrate as many tests from the current Svelte project over to test against the new compiler/runtime.\n\n## Differences to the old test suite\n\n- `compiler` options are different currently, a wrapper function in `helpers.js` was added and call sites rerouted to that\n- regex in the loader was adjusted, a `$` was added to the `import * as ..` regex (because the new runtime does `import * as $ from ..` for the runtime)\n- `vitest.config.js` was altered: `resolve-svelte` plugin also aliases `svelte` (the current runtime import) and `test.dir` was adjusted because the monorepo structure is different (compiler/runtime are separate packages here currently)\n- new runtime does not expose things like raf etc, which were used in some tests (runtime for example; for transition/animation tests). These are commented out for now\n- when changing an attribute, the JSDOM does not reflect the value immediately anymore because the runtime does update the DOM in after a tick, not synchronously - this results in many tests needing additional `await Promise.resolve()` lines\n\n## Breaking changes\n\n- Order of list insertions has changed: It's now back to front because that's faster\n- Slight timing differences mean that things may fire less in some cases (behavior should be unaffected though) - see `component-binding-each-remount-unkeyed` for an example\n- It's currently possible to create infinite loops with `$:` invoking each other\n- Fallback value is now set on all `undefined` values, not just on the first one\n- CSS is no longer minified. Unused styles are instead commented out\n- `:global(...)` compound selectors (e.g. `.foo:global(.bar)` or `:global(.foo).bar`) are no longer permitted. These are nonsensical and don't do anything useful in Svelte 4 — better to just get rid of them\n- transitions: when one element fades out and a new one (which is on the same element but another instance of it) fades in at the same time, the new one is now below the old one (was above before)\n- transitions: now wait one tick before they start playing to align with web animations API\n\n## TODOs\n\n- the new runtime does not expose named exports such as `svelte/store` yet, so can't test those\n- event `this` context is not preserved due to event delegation etc. Problem? Or necessary/ok breaking change?\n- order of operations should be preserved: first all attribute setters (spread props, static props) in order, then mutation directives (actions, bindings) in order, then style/class directives in order\n\n## Tests that succeeded but need a closer look\n\n- `$$slot` was modified to succeed, see TODOs inside for more info\n- `await-component-oncreate` needs to `await Promise.resolve()` because `onMount` runs async, too. Is this ok?\n- `component-slot-fallback-2` has one check commented out, because store subscriptions are deduplicated at the runtime level now. Should this be seen as a breaking change? If yes, ok?\n\n## Tests that are not copied over yet\n\n- everything except runtime is missing so far\n- animation tests within runtime folder were not copied over\n- `beforeUpdate`/`afterUpdate` tests\n",".cursorrules (svelte.mdc)":"---\ndescription: \"Svelte best practices and patterns for modern web applications\"\nglobs: **/*.svelte, src/**/*.ts, src/**/*.js\nalwaysApply: false\n---\n# Svelte Best Practices\n\n## Component Structure\n- Keep components small and focused\n- Use proper TypeScript integration\n- Implement proper props typing\n- Use proper event dispatching\n- Keep markup clean and readable\n- Use proper slot implementation\n\n## Reactivity\n- Use proper reactive declarations\n- Implement proper stores\n- Use proper reactive statements\n- Handle derived values properly\n- Use proper lifecycle functions\n- Implement proper bindings\n\n## State Management\n- Use proper Svelte stores\n- Keep stores modular\n- Use proper derived stores\n- Implement proper actions\n- Handle async state properly\n- Use proper store subscriptions\n\n## Performance\n- Use proper component lazy loading\n- Implement proper transitions\n- Use proper animations\n- Avoid unnecessary reactivity\n- Use proper event forwarding\n- Implement proper key blocks\n\n## Routing\n- Use SvelteKit for routing\n- Implement proper layouts\n- Use proper route parameters\n- Handle loading states properly\n- Implement proper error pages\n- Use proper navigation methods\n\n## Forms\n- Use proper form bindings\n- Implement proper validation\n- Handle form submission properly\n- Show proper loading states\n- Use proper error handling\n- Implement proper form reset\n\n## TypeScript Integration\n- Use proper component types\n- Implement proper prop types\n- Use proper event types\n- Handle proper type inference\n- Use proper store types\n- Implement proper action types\n\n## Testing\n- Write proper unit tests\n- Implement proper component tests\n- Use proper testing libraries\n- Test stores properly\n- Implement proper mocking\n- Test async operations\n\n## Best Practices\n- Follow Svelte style guide\n- Use proper naming conventions\n- Keep components organized\n- Implement proper error handling\n- Use proper event handling\n- Document complex logic\n\n## Build and Tooling\n- Use Vite for development\n- Configure proper build setup\n- Use proper environment variables\n- Implement proper code splitting\n- Use proper asset handling\n- Configure proper optimization\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/sveltejs/svelte/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# Svelte Coding Agent Guide\n\nThis guide is for AI coding agents working in the Svelte monorepo.\n\n**Important:** Read and follow [`CONTRIBUTING.md`](./CONTRIBUTING.md) as well - it contains essential information about testing, code structure, and contribution guidelines that applies here.\n\nWhen submitting a PR, you **MUST** read [`PULL_REQUEST_TEMPLATE.md`](./.github/PULL_REQUEST_TEMPLATE.md) and fill it out correctly. **DO NOT** submit a PR without running the full test suite.\n\n## Security Policy\n\nSee https://github.com/sveltejs/svelte/security/policy.\n\n## Quick Reference\n\nIf asked to do a performance investigation, use the `performance-investigation` skill.\n","isInternal":false,"tokens":150,"sizeBytes":667},{"name":"SKILL.md","path":".agents/skills/performance-investigation/SKILL.md","rawUrl":"https://raw.githubusercontent.com/sveltejs/svelte/HEAD/.agents/skills/performance-investigation/SKILL.md","title":"performance-investigation","category":"anthropic-skill","format":"markdown","content":"---\nname: performance-investigation\ndescription: Investigate performance regressions and find opportunities for optimization\n---\n\n## Quick start\n\n1. Start from a branch you want to measure (for example `foo`).\n2. Run:\n\n```sh\npnpm bench:compare main foo\n```\n\nIf you pass one branch, `bench:compare` automatically compares it to `main`.\n\n## Where outputs go\n\n- Summary report: `benchmarking/compare/.results/report.txt`\n- Raw benchmark numbers:\n  - `benchmarking/compare/.results/main.json`\n  - `benchmarking/compare/.results/<your-branch>.json`\n- CPU profiles (per benchmark, per branch):\n  - `benchmarking/compare/.profiles/main/*.cpuprofile`\n  - `benchmarking/compare/.profiles/main/*.md`\n  - `benchmarking/compare/.profiles/<your-branch>/*.cpuprofile`\n  - `benchmarking/compare/.profiles/<your-branch>/*.md`\n\nThe `.md` files are generated summaries of the CPU profile and are usually the fastest way to inspect hotspots.\n\n## Suggested investigation flow\n\n1. Open `benchmarking/compare/.results/report.txt` and identify largest regressions first.\n2. For each high-delta benchmark, compare:\n   - `benchmarking/compare/.profiles/main/<benchmark>.md`\n   - `benchmarking/compare/.profiles/<branch>/<benchmark>.md`\n3. Look for changes in self/inclusive hotspot share in runtime internals (`runtime.js`, `reactivity/batch.js`, `reactivity/deriveds.js`, `reactivity/sources.js`).\n4. Make one optimization change at a time, then re-run targeted benches before re-running full compare.\n\n## Fast benchmark loops\n\nRun only selected reactivity benchmarks by substring:\n\n```sh\npnpm bench kairo_mux kairo_deep kairo_broad kairo_triangle\npnpm bench repeated_deps sbench_create_signals mol_owned\n```\n\n## Tests to run after perf changes\n\nRuntime reactivity regressions are most likely in runes runtime tests:\n\n```sh\npnpm test runtime-runes\n```\n\n## Helpful script\n\nFor quick cpuprofile hotspot deltas between two branches:\n\n```sh\nnode benchmarking/compare/profile-diff.mjs kairo_mux_owned main foo\n```\n\nThis prints top function sample-share deltas for the selected benchmark.\n\n## Practical gotchas\n\n- `bench:compare` checks out branches while running. Avoid uncommitted changes (or stash them) so branch switching is safe.\n- Each `bench:compare` run rewrites `benchmarking/compare/.results` and `benchmarking/compare/.profiles`.\n","frontmatter":{"name":"performance-investigation","description":"Investigate performance regressions and find opportunities for optimization"},"isInternal":false,"tokens":545,"sizeBytes":2312},{"name":"README.md","path":"packages/svelte/README.md","rawUrl":"https://raw.githubusercontent.com/sveltejs/svelte/HEAD/packages/svelte/README.md","title":"svelte Documentation","category":"plugin-manifest","format":"markdown","content":"<a href=\"https://svelte.dev\">\n\t<picture>\n\t\t<source media=\"(prefers-color-scheme: dark)\" srcset=\"../../assets/banner_dark.png\">\n\t\t<img src=\"../../assets/banner.png\" alt=\"Svelte - web development for the rest of us\" />\n\t</picture>\n</a>\n\n[![npm version](https://img.shields.io/npm/v/svelte.svg)](https://www.npmjs.com/package/svelte) [![license](https://img.shields.io/npm/l/svelte.svg)](LICENSE.md) [![Chat](https://img.shields.io/discord/457912077277855764?label=chat&logo=discord)](https://svelte.dev/chat)\n\n## What is Svelte?\n\nSvelte is a new way to build web applications. It's a compiler that takes your declarative components and converts them into efficient JavaScript that surgically updates the DOM.\n\nLearn more at the [Svelte website](https://svelte.dev), or stop by the [Discord chatroom](https://svelte.dev/chat).\n\n## Getting started\n\nYou can play around with Svelte in the [tutorial](https://svelte.dev/tutorial), [examples](https://svelte.dev/examples), and [REPL](https://svelte.dev/repl).\n\nWhen you're ready to build a full-fledge application, we recommend using [SvelteKit](https://svelte.dev/docs/kit):\n\n```sh\nnpx sv create my-app\ncd my-app\nnpm install\nnpm run dev\n```\n\nSee [the SvelteKit documentation](https://svelte.dev/docs/kit) to learn more.\n\n## Changelog\n\n[The Changelog for this package is available on GitHub](https://github.com/sveltejs/svelte/blob/main/packages/svelte/CHANGELOG.md).\n\n## Supporting Svelte\n\nSvelte is an MIT-licensed open source project with its ongoing development made possible entirely by fantastic volunteers. If you'd like to support their efforts, please consider:\n\n- [Becoming a backer on Open Collective](https://opencollective.com/svelte).\n\nFunds donated via Open Collective will be used for compensating expenses related to Svelte's development.\n","isInternal":false,"tokens":455,"sizeBytes":1799},{"name":"README.md","path":"packages/svelte/tests/README.md","rawUrl":"https://raw.githubusercontent.com/sveltejs/svelte/HEAD/packages/svelte/tests/README.md","title":"tests Documentation","category":"plugin-manifest","format":"markdown","content":"# Test repo\n\nThis repo tries to migrate as many tests from the current Svelte project over to test against the new compiler/runtime.\n\n## Differences to the old test suite\n\n- `compiler` options are different currently, a wrapper function in `helpers.js` was added and call sites rerouted to that\n- regex in the loader was adjusted, a `$` was added to the `import * as ..` regex (because the new runtime does `import * as $ from ..` for the runtime)\n- `vitest.config.js` was altered: `resolve-svelte` plugin also aliases `svelte` (the current runtime import) and `test.dir` was adjusted because the monorepo structure is different (compiler/runtime are separate packages here currently)\n- new runtime does not expose things like raf etc, which were used in some tests (runtime for example; for transition/animation tests). These are commented out for now\n- when changing an attribute, the JSDOM does not reflect the value immediately anymore because the runtime does update the DOM in after a tick, not synchronously - this results in many tests needing additional `await Promise.resolve()` lines\n\n## Breaking changes\n\n- Order of list insertions has changed: It's now back to front because that's faster\n- Slight timing differences mean that things may fire less in some cases (behavior should be unaffected though) - see `component-binding-each-remount-unkeyed` for an example\n- It's currently possible to create infinite loops with `$:` invoking each other\n- Fallback value is now set on all `undefined` values, not just on the first one\n- CSS is no longer minified. Unused styles are instead commented out\n- `:global(...)` compound selectors (e.g. `.foo:global(.bar)` or `:global(.foo).bar`) are no longer permitted. These are nonsensical and don't do anything useful in Svelte 4 — better to just get rid of them\n- transitions: when one element fades out and a new one (which is on the same element but another instance of it) fades in at the same time, the new one is now below the old one (was above before)\n- transitions: now wait one tick before they start playing to align with web animations API\n\n## TODOs\n\n- the new runtime does not expose named exports such as `svelte/store` yet, so can't test those\n- event `this` context is not preserved due to event delegation etc. Problem? Or necessary/ok breaking change?\n- order of operations should be preserved: first all attribute setters (spread props, static props) in order, then mutation directives (actions, bindings) in order, then style/class directives in order\n\n## Tests that succeeded but need a closer look\n\n- `$$slot` was modified to succeed, see TODOs inside for more info\n- `await-component-oncreate` needs to `await Promise.resolve()` because `onMount` runs async, too. Is this ok?\n- `component-slot-fallback-2` has one check commented out, because store subscriptions are deduplicated at the runtime level now. Should this be seen as a breaking change? If yes, ok?\n\n## Tests that are not copied over yet\n\n- everything except runtime is missing so far\n- animation tests within runtime folder were not copied over\n- `beforeUpdate`/`afterUpdate` tests\n","isInternal":false,"tokens":704,"sizeBytes":3120},{"name":".cursorrules","path":".cursorrules (svelte.mdc)","rawUrl":"https://raw.githubusercontent.com/PatrickJS/awesome-cursorrules/main/rules/svelte.mdc","title":"Awesome Cursorrules: svelte","category":"cursor-rule","format":"markdown","content":"---\ndescription: \"Svelte best practices and patterns for modern web applications\"\nglobs: **/*.svelte, src/**/*.ts, src/**/*.js\nalwaysApply: false\n---\n# Svelte Best Practices\n\n## Component Structure\n- Keep components small and focused\n- Use proper TypeScript integration\n- Implement proper props typing\n- Use proper event dispatching\n- Keep markup clean and readable\n- Use proper slot implementation\n\n## Reactivity\n- Use proper reactive declarations\n- Implement proper stores\n- Use proper reactive statements\n- Handle derived values properly\n- Use proper lifecycle functions\n- Implement proper bindings\n\n## State Management\n- Use proper Svelte stores\n- Keep stores modular\n- Use proper derived stores\n- Implement proper actions\n- Handle async state properly\n- Use proper store subscriptions\n\n## Performance\n- Use proper component lazy loading\n- Implement proper transitions\n- Use proper animations\n- Avoid unnecessary reactivity\n- Use proper event forwarding\n- Implement proper key blocks\n\n## Routing\n- Use SvelteKit for routing\n- Implement proper layouts\n- Use proper route parameters\n- Handle loading states properly\n- Implement proper error pages\n- Use proper navigation methods\n\n## Forms\n- Use proper form bindings\n- Implement proper validation\n- Handle form submission properly\n- Show proper loading states\n- Use proper error handling\n- Implement proper form reset\n\n## TypeScript Integration\n- Use proper component types\n- Implement proper prop types\n- Use proper event types\n- Handle proper type inference\n- Use proper store types\n- Implement proper action types\n\n## Testing\n- Write proper unit tests\n- Implement proper component tests\n- Use proper testing libraries\n- Test stores properly\n- Implement proper mocking\n- Test async operations\n\n## Best Practices\n- Follow Svelte style guide\n- Use proper naming conventions\n- Keep components organized\n- Implement proper error handling\n- Use proper event handling\n- Document complex logic\n\n## Build and Tooling\n- Use Vite for development\n- Configure proper build setup\n- Use proper environment variables\n- Implement proper code splitting\n- Use proper asset handling\n- Configure proper optimization\n","tokens":436,"sizeBytes":2149}],"systemPromptSnippet":"<yakaai_skills repo=\"sveltejs/svelte\">\n<!-- File: AGENTS.md (Tokens: ~150 | Category: root-instruction) -->\n# Svelte Coding Agent Guide\n\nThis guide is for AI coding agents working in the Svelte monorepo.\n\n**Important:** Read and follow [`CONTRIBUTING.md`](./CONTRIBUTING.md) as well - it contains essential information about testing, code structure, and contribution guidelines that applies here.\n\nWhen submitting a PR, you **MUST** read [`PULL_REQUEST_TEMPLATE.md`](./.github/PULL_REQUEST_TEMPLATE.md) and fill it out correctly. **DO NOT** submit a PR without running the full test suite.\n\n## Security Policy\n\nSee https://github.com/sveltejs/svelte/security/policy.\n\n## Quick Reference\n\nIf asked to do a performance investigation, use the `performance-investigation` skill.\n\n<!-- File: .agents/skills/performance-investigation/SKILL.md (Tokens: ~545 | Category: anthropic-skill) -->\n---\nname: performance-investigation\ndescription: Investigate performance regressions and find opportunities for optimization\n---\n\n## Quick start\n\n1. Start from a branch you want to measure (for example `foo`).\n2. Run:\n\n```sh\npnpm bench:compare main foo\n```\n\nIf you pass one branch, `bench:compare` automatically compares it to `main`.\n\n## Where outputs go\n\n- Summary report: `benchmarking/compare/.results/report.txt`\n- Raw benchmark numbers:\n  - `benchmarking/compare/.results/main.json`\n  - `benchmarking/compare/.results/<your-branch>.json`\n- CPU profiles (per benchmark, per branch):\n  - `benchmarking/compare/.profiles/main/*.cpuprofile`\n  - `benchmarking/compare/.profiles/main/*.md`\n  - `benchmarking/compare/.profiles/<your-branch>/*.cpuprofile`\n  - `benchmarking/compare/.profiles/<your-branch>/*.md`\n\nThe `.md` files are generated summaries of the CPU profile and are usually the fastest way to inspect hotspots.\n\n## Suggested investigation flow\n\n1. Open `benchmarking/compare/.results/report.txt` and identify largest regressions first.\n2. For each high-delta benchmark, compare:\n   - `benchmarking/compare/.profiles/main/<benchmark>.md`\n   - `benchmarking/compare/.profiles/<branch>/<benchmark>.md`\n3. Look for changes in self/inclusive hotspot share in runtime internals (`runtime.js`, `reactivity/batch.js`, `reactivity/deriveds.js`, `reactivity/sources.js`).\n4. Make one optimization change at a time, then re-run targeted benches before re-running full compare.\n\n## Fast benchmark loops\n\nRun only selected reactivity benchmarks by substring:\n\n```sh\npnpm bench kairo_mux kairo_deep kairo_broad kairo_triangle\npnpm bench repeated_deps sbench_create_signals mol_owned\n```\n\n## Tests to run after perf changes\n\nRuntime reactivity regressions are most likely in runes runtime tests:\n\n```sh\npnpm test runtime-runes\n```\n\n## Helpful script\n\nFor quick cpuprofile hotspot deltas between two branches:\n\n```sh\nnode benchmarking/compare/profile-diff.mjs kairo_mux_owned main foo\n```\n\nThis prints top function sample-share deltas for the selected benchmark.\n\n## Practical gotchas\n\n- `bench:compare` checks out branches while running. Avoid uncommitted changes (or stash them) so branch switching is safe.\n- Each `bench:compare` run rewrites `benchmarking/compare/.results` and `benchmarking/compare/.profiles`.\n\n<!-- File: packages/svelte/README.md (Tokens: ~455 | Category: plugin-manifest) -->\n<a href=\"https://svelte.dev\">\n\t<picture>\n\t\t<source media=\"(prefers-color-scheme: dark)\" srcset=\"../../assets/banner_dark.png\">\n\t\t<img src=\"../../assets/banner.png\" alt=\"Svelte - web development for the rest of us\" />\n\t</picture>\n</a>\n\n[![npm version](https://img.shields.io/npm/v/svelte.svg)](https://www.npmjs.com/package/svelte) [![license](https://img.shields.io/npm/l/svelte.svg)](LICENSE.md) [![Chat](https://img.shields.io/discord/457912077277855764?label=chat&logo=discord)](https://svelte.dev/chat)\n\n## What is Svelte?\n\nSvelte is a new way to build web applications. It's a compiler that takes your declarative components and converts them into efficient JavaScript that surgically updates the DOM.\n\nLearn more at the [Svelte website](https://svelte.dev), or stop by the [Discord chatroom](https://svelte.dev/chat).\n\n## Getting started\n\nYou can play around with Svelte in the [tutorial](https://svelte.dev/tutorial), [examples](https://svelte.dev/examples), and [REPL](https://svelte.dev/repl).\n\nWhen you're ready to build a full-fledge application, we recommend using [SvelteKit](https://svelte.dev/docs/kit):\n\n```sh\nnpx sv create my-app\ncd my-app\nnpm install\nnpm run dev\n```\n\nSee [the SvelteKit documentation](https://svelte.dev/docs/kit) to learn more.\n\n## Changelog\n\n[The Changelog for this package is available on GitHub](https://github.com/sveltejs/svelte/blob/main/packages/svelte/CHANGELOG.md).\n\n## Supporting Svelte\n\nSvelte is an MIT-licensed open source project with its ongoing development made possible entirely by fantastic volunteers. If you'd like to support their efforts, please consider:\n\n- [Becoming a backer on Open Collective](https://opencollective.com/svelte).\n\nFunds donated via Open Collective will be used for compensating expenses related to Svelte's development.\n\n<!-- File: packages/svelte/tests/README.md (Tokens: ~704 | Category: plugin-manifest) -->\n# Test repo\n\nThis repo tries to migrate as many tests from the current Svelte project over to test against the new compiler/runtime.\n\n## Differences to the old test suite\n\n- `compiler` options are different currently, a wrapper function in `helpers.js` was added and call sites rerouted to that\n- regex in the loader was adjusted, a `$` was added to the `import * as ..` regex (because the new runtime does `import * as $ from ..` for the runtime)\n- `vitest.config.js` was altered: `resolve-svelte` plugin also aliases `svelte` (the current runtime import) and `test.dir` was adjusted because the monorepo structure is different (compiler/runtime are separate packages here currently)\n- new runtime does not expose things like raf etc, which were used in some tests (runtime for example; for transition/animation tests). These are commented out for now\n- when changing an attribute, the JSDOM does not reflect the value immediately anymore because the runtime does update the DOM in after a tick, not synchronously - this results in many tests needing additional `await Promise.resolve()` lines\n\n## Breaking changes\n\n- Order of list insertions has changed: It's now back to front because that's faster\n- Slight timing differences mean that things may fire less in some cases (behavior should be unaffected though) - see `component-binding-each-remount-unkeyed` for an example\n- It's currently possible to create infinite loops with `$:` invoking each other\n- Fallback value is now set on all `undefined` values, not just on the first one\n- CSS is no longer minified. Unused styles are instead commented out\n- `:global(...)` compound selectors (e.g. `.foo:global(.bar)` or `:global(.foo).bar`) are no longer permitted. These are nonsensical and don't do anything useful in Svelte 4 — better to just get rid of them\n- transitions: when one element fades out and a new one (which is on the same element but another instance of it) fades in at the same time, the new one is now below the old one (was above before)\n- transitions: now wait one tick before they start playing to align with web animations API\n\n## TODOs\n\n- the new runtime does not expose named exports such as `svelte/store` yet, so can't test those\n- event `this` context is not preserved due to event delegation etc. Problem? Or necessary/ok breaking change?\n- order of operations should be preserved: first all attribute setters (spread props, static props) in order, then mutation directives (actions, bindings) in order, then style/class directives in order\n\n## Tests that succeeded but need a closer look\n\n- `$$slot` was modified to succeed, see TODOs inside for more info\n- `await-component-oncreate` needs to `await Promise.resolve()` because `onMount` runs async, too. Is this ok?\n- `component-slot-fallback-2` has one check commented out, because store subscriptions are deduplicated at the runtime level now. Should this be seen as a breaking change? If yes, ok?\n\n## Tests that are not copied over yet\n\n- everything except runtime is missing so far\n- animation tests within runtime folder were not copied over\n- `beforeUpdate`/`afterUpdate` tests\n\n<!-- File: .cursorrules (svelte.mdc) (Tokens: ~436 | Category: cursor-rule) -->\n---\ndescription: \"Svelte best practices and patterns for modern web applications\"\nglobs: **/*.svelte, src/**/*.ts, src/**/*.js\nalwaysApply: false\n---\n# Svelte Best Practices\n\n## Component Structure\n- Keep components small and focused\n- Use proper TypeScript integration\n- Implement proper props typing\n- Use proper event dispatching\n- Keep markup clean and readable\n- Use proper slot implementation\n\n## Reactivity\n- Use proper reactive declarations\n- Implement proper stores\n- Use proper reactive statements\n- Handle derived values properly\n- Use proper lifecycle functions\n- Implement proper bindings\n\n## State Management\n- Use proper Svelte stores\n- Keep stores modular\n- Use proper derived stores\n- Implement proper actions\n- Handle async state properly\n- Use proper store subscriptions\n\n## Performance\n- Use proper component lazy loading\n- Implement proper transitions\n- Use proper animations\n- Avoid unnecessary reactivity\n- Use proper event forwarding\n- Implement proper key blocks\n\n## Routing\n- Use SvelteKit for routing\n- Implement proper layouts\n- Use proper route parameters\n- Handle loading states properly\n- Implement proper error pages\n- Use proper navigation methods\n\n## Forms\n- Use proper form bindings\n- Implement proper validation\n- Handle form submission properly\n- Show proper loading states\n- Use proper error handling\n- Implement proper form reset\n\n## TypeScript Integration\n- Use proper component types\n- Implement proper prop types\n- Use proper event types\n- Handle proper type inference\n- Use proper store types\n- Implement proper action types\n\n## Testing\n- Write proper unit tests\n- Implement proper component tests\n- Use proper testing libraries\n- Test stores properly\n- Implement proper mocking\n- Test async operations\n\n## Best Practices\n- Follow Svelte style guide\n- Use proper naming conventions\n- Keep components organized\n- Implement proper error handling\n- Use proper event handling\n- Document complex logic\n\n## Build and Tooling\n- Use Vite for development\n- Configure proper build setup\n- Use proper environment variables\n- Implement proper code splitting\n- Use proper asset handling\n- Configure proper optimization\n</yakaai_skills>"}