{"owner":"alpinejs","repo":"alpine","hasSkills":true,"totalSkillsCount":60,"totalTokensCount":64959,"categories":["anthropic-skill","claude-rule"],"hasMcp":false,"mcpConfig":null,"found":[".claude/skills/review-pr/SKILL.md",".claude/skills/summarize-activity/SKILL.md","CLAUDE.md","packages/docs/package.json","packages/docs/src/en/advanced.md","packages/docs/src/en/advanced/async.md","packages/docs/src/en/advanced/csp.md","packages/docs/src/en/advanced/extending.md","packages/docs/src/en/advanced/reactivity.md","packages/docs/src/en/directives.md","packages/docs/src/en/directives/bind.md","packages/docs/src/en/directives/cloak.md","packages/docs/src/en/directives/data.md","packages/docs/src/en/directives/effect.md","packages/docs/src/en/directives/for.md","packages/docs/src/en/directives/html.md","packages/docs/src/en/directives/id.md","packages/docs/src/en/directives/if.md","packages/docs/src/en/directives/ignore.md","packages/docs/src/en/directives/init.md","packages/docs/src/en/directives/model.md","packages/docs/src/en/directives/modelable.md","packages/docs/src/en/directives/on.md","packages/docs/src/en/directives/ref.md","packages/docs/src/en/directives/show.md","packages/docs/src/en/directives/teleport.md","packages/docs/src/en/directives/text.md","packages/docs/src/en/directives/transition.md","packages/docs/src/en/essentials.md","packages/docs/src/en/essentials/events.md","packages/docs/src/en/essentials/installation.md","packages/docs/src/en/essentials/lifecycle.md","packages/docs/src/en/essentials/state.md","packages/docs/src/en/essentials/templating.md","packages/docs/src/en/globals.md","packages/docs/src/en/globals/alpine-bind.md","packages/docs/src/en/globals/alpine-data.md","packages/docs/src/en/globals/alpine-store.md","packages/docs/src/en/magics.md","packages/docs/src/en/magics/data.md","packages/docs/src/en/magics/dispatch.md","packages/docs/src/en/magics/el.md","packages/docs/src/en/magics/id.md","packages/docs/src/en/magics/nextTick.md","packages/docs/src/en/magics/refs.md","packages/docs/src/en/magics/root.md","packages/docs/src/en/magics/store.md","packages/docs/src/en/magics/watch.md","packages/docs/src/en/plugins.md","packages/docs/src/en/plugins/anchor.md","packages/docs/src/en/plugins/collapse.md","packages/docs/src/en/plugins/focus.md","packages/docs/src/en/plugins/intersect.md","packages/docs/src/en/plugins/mask.md","packages/docs/src/en/plugins/morph.md","packages/docs/src/en/plugins/persist.md","packages/docs/src/en/plugins/resize.md","packages/docs/src/en/plugins/sort.md","packages/docs/src/en/start-here.md","packages/docs/src/en/upgrade-guide.md"],"skills":{".claude/skills/review-pr/SKILL.md":"---\nname: review-pr\ndescription: Review an open PR like a maintainer — checkout, fix issues, push changes, post a structured verdict comment. You just merge or close.\ndisable-model-invocation: true\nallowed-tools: Bash, Read, Glob, Grep, Edit, Write, Task\nargument-hint: \"[PR number (optional - picks latest if omitted)]\"\n---\n\n# /review-pr - Maintainer-style PR review bot\n\nYou are a strict, opinionated maintainer of the Alpine.js project. Your job: review a PR, fix what you can, push fixes, and post a verdict comment so Caleb can just merge or close.\n\n**IMPORTANT: Every numbered step below is mandatory. Do not skip steps, do not substitute your own approach, do not rationalize \"I already have this data from somewhere else.\" Run the exact commands listed. If a command fails, retry it — do not silently move on. Complete each step fully before starting the next.**\n\n## Step 1: Pick a PR\n\nIf `$ARGUMENTS` is provided, use that as the PR number. Otherwise, pick the latest open PR:\n\n```bash\ngh pr list --state open --limit 1 --json number -q '.[0].number'\n```\n\n## Step 2: Check if already reviewed\n\nLook for the `` marker in PR comments:\n\n```bash\ngh pr view {number} --json comments -q '.comments[].body' | grep -q ''\n```\n\nIf found, tell the user this PR was already reviewed and stop. Unless `$ARGUMENTS` explicitly includes `--force` or the user asks to re-review.\n\n## Step 3: Fetch PR data\n\nRun ALL FOUR of these commands in parallel. If any fail, retry them. Do not proceed to Step 4 until you have output from all four:\n\n```bash\ngh pr view {number} --json title,body,author,state,labels,comments,reviews,files,additions,deletions,baseRefName,headRefName,createdAt,updatedAt,reviewDecision,statusCheckRollup,url\ngh pr diff {number}\ngh pr checks {number}\ngh api repos/{owner}/{repo}/issues/{number}/reactions\n```\n\n## Step 4: Checkout locally and merge main\n\n```bash\ngh pr checkout {number}\ngit merge main\n```\n\nAlways merge main into the PR branch before reviewing. This ensures you have the latest project files (rules, skills, docs) and avoids reviewing against stale code. If the merge has conflicts, resolve them or flag for the contributor.\n\n## Step 5: Read and classify\n\nRead through the diff and PR body. Classify the PR:\n\n- **Bug fix** - Fixes broken behavior\n- **Feature** - Adds new functionality\n- **Refactor** - Restructures without changing behavior\n- **Docs** - Documentation only\n- **Mixed** - Multiple categories (flag this as a concern)\n\n## Step 6: Challenge the contributor's framing\n\nDon't accept the PR description's framing of the bug or problem at face value. Verify independently:\n\n1. **Identify the root cause yourself.** Read the code the PR modifies. Understand *why* the bug exists before looking at how the PR fixes it.\n2. **Does the test actually isolate that root cause?** Or does it test through incidental complexity the contributor happened to encounter? If the test would still pass after removing the actual fix, it's testing the wrong thing.\n3. **If the test encodes a wrong mental model, rewrite it.** Strip it to the minimum reproduction that targets the real bug. Tests are documentation — they should communicate the bug precisely, not replay the contributor's debugging journey.\n4. **Challenge the implementation architecture, not just the problem framing.** When simplifying a PR, don't just strip parameters — ask whether the contributor's fundamental approach is the right one. A simpler version of a bad approach is still a bad approach. Ask: \"What's the laziest correct solution? Does the language/framework already handle this if I just let it?\"\n\n## Step 7: Evaluate\n\n### For bug fixes\n\n1. **Has a test?** If not, write one. The test should fail on `main` and pass on the PR branch.\n2. **Test covers the actual fix?** Including edge cases?\n3. **Actually verify regression.** Don't just reason about whether the test fails without the fix — prove it. Stash the fix (`git stash -- `), rebuild (`npm run build`), run the test. If it passes without the fix, the test is not testing the fix. Unstash and rewrite the test. This is non-negotiable for bug fix PRs.\n4. **Test isolates root cause?** Does the test target the actual bug, or does it test through incidental complexity the contributor happened to encounter? Strip tests to the minimum reproduction. Tests are documentation — they should communicate the bug precisely.\n5. **Naming quality?** Review all test names, component names, variable names. Contributors often use names that reflect their mental model, not the actual architecture. Fix these before merging — they become permanent.\n6. **Unnecessary fixtures/setup?** If the test introduces helper files, imports, or setup that aren't essential to reproducing the bug, remove them.\n7. **For visual/browser bugs, test observable behavior, not DOM state.** Assertions like \"element is present\" or \"attribute is set\" can pass while the visual bug persists. For animation bugs: assert on `document.getAnimations()` state. For style bugs: assert on computed styles or style properties after the relevant lifecycle completes. For timing bugs: use assertions that would produce different results with and without the fix.\n8. **Fix is surgical/minimal?** No unrelated changes?\n9. **Regression risk?** Could this break something else?\n\n### For features\n\nAddress EVERY item below. Do not skip any — even to say \"N/A\":\n\n1. **Already possible without new API?** Default stance: reject new public API surface. Trace the full existing code path before evaluating the new one — the use case may already be solvable. New directives/modifiers/magic properties are maintained forever; only add when there's no existing path.\n2. **Community demand?** Check reactions on the PR and linked issues. Low engagement = higher bar.\n3. **Intuitive API?** Single-word modifiers preferred (`x-transition.opacity` not `x-transition.opacity-only`). Alpine favors short, expressive directive syntax.\n4. **Precedent?** Does it build on existing patterns or introduce new ones? New patterns need strong justification.\n5. **Scope?** Should this be a core Alpine feature or a separate plugin package? Alpine core should stay minimal.\n6. **Docs included?** Features need documentation.\n7. **Registration complete?** Check that new directives/magics/plugins are properly registered and exported.\n\n### For all PRs\n\nAddress EVERY item below:\n\n1. **Project style?**\n - JS: no semicolons, `let` not `const`\n - Follows Alpine's existing patterns and conventions\n2. **Single responsibility?** Flag PRs doing too many things.\n3. **Security?** Extra scrutiny for: `x-html`, expression evaluation, `Alpine.evaluate()`, anything touching user-provided expressions or the reactive system.\n4. **Built JS assets in diff?** Check the file list from `gh pr diff --name-only` for `dist/` files. These should NOT be committed. Remove them.\n5. **\"No for now\" bias.** When in doubt, lean toward not merging. It's easier to add later than remove.\n6. **Async timing fixes are treacherous.** When a PR fixes a bug involving microtask/macrotask timing (Alpine effects, `nextTick`, `queueMicrotask`, `MutationObserver` scheduling): don't trust that the approach works just because the reasoning sounds right. Alpine's reactivity scheduler uses multi-hop `queueMicrotask` chains — a single `queueMicrotask` or even `setTimeout(0)` may not be enough. If you can't verify the timing empirically, flag it for discussion.\n7. **\"What's the laziest correct solution?\"** Before evaluating the PR's implementation details, independently brainstorm the simplest possible fix. The contributor's approach is often shaped by their discovery path, not by what's optimal.\n\n## Step 8: Run relevant tests only\n\n**NEVER run the full test suite.** Only run tests the PR adds or touches:\n\n```bash\n# Find test files in the diff\ngh pr diff {number} --name-only | grep -E '\\.spec\\.js$'\n```\n\nRun those specific tests:\n\n```bash\n# For Cypress browser tests\nnpx cypress run --spec ./tests/cypress/integration/{test-file}.spec.js\n\n# For Vitest unit tests\nnpx vitest run tests/vitest/{test-file}.spec.js\n```\n\nIf the PR doesn't touch test files but you wrote tests in step 6, run those.\n\nAlso check CI status:\n\n```bash\ngh pr checks {number}\n```\n\n## Step 8b: If the PR has no fix, write one\n\nIf the PR only adds a failing test (or describes a bug without a fix), don't just review the test and stop. **Explore solution paths and try to fix the bug yourself.** This is the most valuable thing you can do.\n\n1. Identify 2-3 possible fix approaches\n2. Evaluate trade-offs of each (surgical vs broad, risk of regressions, etc.)\n3. Present the options to Caleb with a brief explanation of each\n4. Once Caleb picks a direction, implement and test it\n\n## Step 9: Make fixes directly\n\nFix issues you find. Common fixes:\n\n- **Style violations**: Remove semicolons from JS, change `const` to `let`\n- **Built assets in diff**: `git checkout main -- dist/` (or whatever the build output path is)\n- **Missing tests**: Write them\n- **Small refactors**: Simplify overly complex code\n- **Missing registration**: Add to package index files, etc.\n- **Before committing a simplified version of the contributor's code, do a smell test:** Could this be done in fewer lines with a completely different approach? The best code is the code you delete.\n\nStage and commit fixes:\n\n```bash\ngit add -A\ngit commit -m \"Review fixes: [brief description]\n\nCo-Authored-By: Claude Opus 4.6 \"\n```\n\n## Step 10: Push to PR branch\n\nTry to push to the contributor's branch:\n\n```bash\ngit push\n```\n\n### If push fails (fork doesn't allow maintainer edits)\n\n1. Create a new branch from `main`\n2. Cherry-pick the contributor's commits\n3. Apply your fixes on top\n4. Push the new branch\n5. Create a new PR:\n\n```bash\ngh pr create --title \"{original title}\" --body \"$(cat <<'EOF'\nCloses #{original_number}\n\nCherry-picked from #{original_number} by @{author} with review fixes applied.\n\n## Original description\n{original_body}\n\n## Review fixes applied\n{list of fixes}\nEOF\n)\"\n```\n\n6. Comment on the original PR explaining the new PR.\n\n## Step 11: Post verdict comment\n\nPost a structured comment on the PR:\n\n```bash\ngh pr comment {number} --body \"$(cat <<'EOF'\n\n## PR Review: #{number} — {title}\n\n**Type**: {Bug fix | Feature | Refactor | Docs | Mixed}\n**Verdict**: {Merge | Request changes | Needs discussion | Close}\n\n### What's happening (plain English)\n{Explain the PR like Caleb is a 3-year-old who happens to be an expert in Alpine internals but has zero context on this specific PR. Use a numbered step-by-step walkthrough of the exact sequence that triggers the bug/feature. No jargon beyond what Alpine devs already know. Be crystal clear and concise — this is the most important section.}\n\n### Other approaches considered\n{Briefly list 2-3 alternative ways this could have been solved, with one sentence each on why the PR's approach is better (or worse). If there's only one reasonable approach, say so and explain why. This helps Caleb quickly evaluate whether the chosen path is the right one.}\n\n### Changes Made\n{List of fixups you pushed, or \"No changes made\" if none}\n\n### Test Results\n{Which tests ran, pass/fail status, CI status}\n\n### Code Review\n{Specific feedback with file:line references. What's good, what's concerning.}\n\n### Security\n{Any security considerations, or \"No security concerns identified.\"}\n\n### Verdict\n{Your reasoning for the verdict. Be direct. If it should be merged, say why. If closed, say why kindly but clearly.}\n\n---\n*Reviewed by Claude*\nEOF\n)\"\n```\n\n## Verdict guidelines\n\n- **Merge**: Code is correct, tests pass, style is clean, feature is wanted. You've fixed any minor issues.\n- **Request changes**: Significant issues you can't fix yourself (architectural problems, missing context, needs author input).\n- **Needs discussion**: Feature scope questions, API design debates, core vs plugin questions. Tag these for Caleb.\n- **Close**: PR is stale with no response, duplicates existing functionality, or solves a problem that shouldn't be solved. Be kind.\n\n## Important rules\n\n- NEVER run the full test suite. Only run tests the PR touches or that you wrote.\n- Always use the `` marker so you can detect previous reviews.\n- Be opinionated. This project has strong conventions — enforce them.\n- Fix what you can. Don't just point out problems if you can solve them.\n- Security is non-negotiable. If you see a security issue, verdict is always \"Request changes\" regardless of everything else.\n- Match the project voice: practical, direct, minimal.\n- Don't accept the contributor's framing of the problem at face value. Verify the root cause independently, then ensure the test targets that root cause — not the contributor's incidental path to discovering it.\n- \"Should this exist?\" before \"Is this correct?\" — Don't get pulled into reviewing implementation details (code quality, edge cases, naming) until you've decided the feature itself is justified. Implementation nits imply acceptance.\n- Tests are documentation. A sloppy test that passes is not good enough — it should precisely communicate what broke and why.\n- Review contributor naming as critically as contributor code. Bad names get merged and become permanent.\n",".claude/skills/summarize-activity/SKILL.md":"---\nname: summarize-activity\ndescription: Summarize recent GitHub activity — discussions, PRs, issues, events, traffic — into an actionable report so you can stay on top of the project without reading everything.\ndisable-model-invocation: true\nallowed-tools: Bash, Read, Task\nargument-hint: \"[timeframe: 24h (default), 48h, 7d, 1w]\"\n---\n\n# /summarize-activity - GitHub activity digest\n\nYou generate a concise, actionable summary of recent Alpine.js GitHub activity for Caleb.\n\n**IMPORTANT: Every numbered step below is mandatory. Do not skip steps, do not substitute your own approach. Run the exact commands listed. If a command fails, retry it — do not silently move on. Complete each step fully before starting the next.**\n\n## Step 1: Parse timeframe\n\nParse `$ARGUMENTS` into a cutoff timestamp. Supported formats:\n- `24h`, `48h`, `72h` — hours (default: `24h` if no argument)\n- `7d`, `14d`, `30d` — days\n- `1w`, `2w` — weeks (1w = 7d)\n\nCompute the ISO 8601 cutoff timestamp:\n\n```bash\n# Example for 24h:\ndate -u -v-24H '+%Y-%m-%dT%H:%M:%SZ'\n# Example for 7d:\ndate -u -v-7d '+%Y-%m-%dT%H:%M:%SZ'\n```\n\nStore the cutoff timestamp and the human-readable timeframe label (e.g., \"last 24 hours\", \"last 7 days\") for use in later steps.\n\n## Step 2: Fetch activity in parallel\n\nRun ALL FIVE of these commands in parallel using the Bash tool. If any fail, retry them. Do not proceed to Step 3 until you have output from all five.\n\n**Owner/repo:** `alpinejs/alpine`\n\n### 2a. Discussions (GraphQL)\n\n```bash\ngh api graphql -f query='\n{\n repository(owner: \"alpinejs\", name: \"alpine\") {\n discussions(first: 50, orderBy: {field: UPDATED_AT, direction: DESC}) {\n nodes {\n title\n url\n author { login }\n category { name }\n comments { totalCount }\n body\n answer { author { login } body createdAt }\n createdAt\n updatedAt\n }\n }\n }\n}'\n```\n\n### 2b. Pull Requests\n\n```bash\ngh pr list --repo alpinejs/alpine --state all --limit 50 --json number,title,url,author,state,labels,createdAt,updatedAt,additions,deletions,headRefName,baseRefName,reviewDecision,comments\n```\n\n### 2c. Issues\n\n```bash\ngh issue list --repo alpinejs/alpine --state all --limit 50 --json number,title,url,author,state,labels,createdAt,updatedAt,comments\n```\n\n### 2d. Events\n\n```bash\ngh api repos/alpinejs/alpine/events --paginate --jq '.[] | {type, actor: .actor.login, created_at: .created_at, payload_action: .payload.action, ref: .payload.ref, ref_type: .payload.ref_type}' | head -100\n```\n\n### 2e. Traffic & stars\n\n```bash\ngh api repos/alpinejs/alpine/traffic/views 2>/dev/null; echo \"---SEPARATOR---\"; gh api repos/alpinejs/alpine/traffic/clones 2>/dev/null; echo \"---SEPARATOR---\"; gh api repos/alpinejs/alpine --jq '{stargazers_count, forks_count, open_issues_count, watchers_count}'\n```\n\nNote: Traffic endpoints require push access. If they return 403, skip traffic data and note it in the report.\n\n## Step 3: Fetch comment threads for active items\n\nFor discussions that have comments updated within the timeframe, fetch full comment bodies via GraphQL. Batch up to 10 discussions per query:\n\n```bash\ngh api graphql -f query='\n{\n repository(owner: \"alpinejs\", name: \"alpine\") {\n discussion(number: {NUMBER}) {\n comments(last: 10) {\n nodes {\n author { login }\n body\n createdAt\n updatedAt\n }\n }\n }\n }\n}'\n```\n\nFor the most active PRs and issues (those with comments updated in timeframe), fetch recent comments:\n\n```bash\ngh api repos/alpinejs/alpine/issues/{number}/comments --jq '.[] | select(.updated_at > \"{CUTOFF}\") | {user: .user.login, body: .body, created_at: .created_at}'\n```\n\nOnly fetch threads that are clearly within the timeframe. Don't fetch everything — be selective.\n\n## Step 4: Filter by timeframe\n\nDiscard anything with `updatedAt` / `updated_at` before the cutoff timestamp. Keep items where:\n- The item was created within the timeframe\n- The item received new comments within the timeframe\n- The item changed state (opened, closed, merged) within the timeframe\n\n## Step 5: Analyze and write report\n\nOutput a markdown report with these sections. Be concise — this is a digest, not a novel.\n\n---\n\n### Report format:\n\n```markdown\n# Alpine.js Activity — {timeframe label}\n_{start date} to {end date}_\n\n## TL;DR\n{2-3 sentences. What's the pulse? Any fires? Anything exciting? Give Caleb the vibe in 10 seconds.}\n\n## Needs Your Attention\n{Actionable items only. Each with a recommended next step: reply, merge, close, investigate, etc.}\n\n- **[Title](url)** by @author — {why it needs attention}. **Action:** {specific recommendation}\n\n{If nothing needs attention, say \"Nothing urgent right now.\"}\n\n## Hot Discussions\n{Discussions with the most activity or notable sentiment. Include key quotes if illuminating.}\n\n- **[Title](url)** ({category}) — {N} comments — {brief summary, sentiment note}\n\n{If no notable discussions, say \"Quiet on the discussion front.\"}\n\n## PR Activity\n\n### Opened\n- **[#N Title](url)** by @author — {one-line summary} {+additions/-deletions}\n\n### Merged\n- **[#N Title](url)** by @author — {one-line summary}\n\n### Closed (not merged)\n- **[#N Title](url)** by @author — {one-line summary, why closed if clear}\n\n{Omit empty subsections.}\n\n## Issue Activity\n\n### Opened\n- **[#N Title](url)** by @author — {one-line summary}\n\n### Closed\n- **[#N Title](url)** — {one-line summary}\n\n{Omit empty subsections.}\n\n## Repo Pulse\n| Metric | Value |\n|--------|-------|\n| Stars | {total} |\n| Views (14d) | {count} |\n| Clones (14d) | {count} |\n| Open issues | {count} |\n| PRs opened | {count in timeframe} |\n| PRs merged | {count in timeframe} |\n| PRs closed | {count in timeframe} |\n\n{If traffic data is unavailable (403), omit those rows and note \"Traffic data requires push access.\"}\n```\n\n---\n\n## Important rules\n\n- Every item must include a `[title](url)` link so Caleb can click through.\n- Include @author for attribution.\n- Keep summaries to ONE line per item. This is a digest.\n- The \"Needs Your Attention\" section is the most important. Be opinionated about what deserves Caleb's time.\n- If a discussion or issue has heated sentiment, note it (e.g., \"heated\", \"confused users\", \"strong demand\").\n- Omit empty sections entirely — don't show \"No activity\" headers.\n- For PRs, mention if CI is failing when relevant.\n- Don't editorialize beyond what's helpful for triage. Be practical, not chatty.\n","CLAUDE.md":"# Alpine.js Development Guidelines\n\n## Pull Request Evaluation Criteria\n\nWhen evaluating pull requests for Alpine.js, assess the following:\n\n### 1. Tests\n- Are tests provided for the change?\n- Do existing tests still pass?\n- For configuration changes (package.json, build scripts), tests may not be required\n\n### 2. Code Style\n- Does the code match Alpine's existing patterns?\n- Check indentation, naming conventions, and structure\n- For package.json changes, ensure consistency with other packages in the monorepo\n\n### 3. Code Quality\n- Is the code clean and maintainable?\n- Is the change focused and minimal?\n- Are there any unnecessary changes or complexity?\n- Does this PR contain changes that should apply elsewhere?\n\n### 4. Simplicity\n- Is this a simple, focused change?\n- Does it follow Alpine's philosophy of simplicity?\n- Could it be implemented more simply?\n- Are the proposed additions intuitive for users? or do they require extra knowledge that they have to dig for.\n\n### 5. Precedent\n- Does this PR (both public facing additions and internal implementation) follow established precedents in the project\n- Does it use terms that are unfamiliar to the project as of yet?\n\n### 6. Description Quality\n- Is there a clear explanation of what/why/how?\n- Are breaking changes documented?\n- Is backward compatibility addressed?\n\n### 7. Community Engagement\n- Are there comments, reviews, or discussions?\n- Has it been approved by maintainers?\n- Are there any conflicting opinions or unresolved concerns?\n\n### Mergeability Rating\nBased on the above, rate as:\n- **HIGH**: Ready to merge (all criteria met, approved)\n- **MEDIUM**: Needs attention (technically sound but missing reviews/tests)\n- **LOW**: Requires work (has issues or conflicts to resolve)\n\n## Project Structure\n\nAlpine.js is a monorepo with packages in `/packages/`:\n- Each package has its own package.json\n- Build outputs go to `dist/` with `.cjs.js`, `.esm.js`, and `.min.js` versions\n- Browser tests use Cypress, unit tests use Vitest\n- CI runs on GitHub Actions\n\n## Common Commands\n\n```bash\n# Build\nnpm run build # Build all packages\n\n# Browser tests (Cypress)\nnpm test # Run all tests\nnpx cypress run --spec ./tests/cypress/integration/[filename].spec.js # Run single spec\n\n# Unit tests (Vitest)\nnpx vitest run tests/vitest/[filename].spec.js # Run single spec\n\n# Review PRs\ngh pr list # List open PRs\ngh pr view [number] # View PR details\ngh pr diff [number] # View code changes\ngh pr checks [number] # Check CI status\n```\n\n## Manual Testing\n\n1. Edit `./index.html` at project root\n2. Open in browser at `http://alpine.test/` (assumes local dev server mapped to directory name)\n\n## Summary\n\nAfter assessing the pull request on the above qualities, provide a summary explaining the problem this PR addresses and the fix, and why it's a good or bad fix. Do it in plain language as if you are personally advising me on what the PR is and weather or not I should merge it. And if not, what might need to be addressed first. If things need to be addressed, offer to address them yourself.\n\nPlease use code snippets to establish a starting point and and ending point if helpful. For example, when explaining the problem, it is often easier to provide a brief explanation alongside a code snippet of what is currently problematic, then when explaining the solution, showing what new code will allow a fix if applicable.","packages/docs/package.json":"{\n \"name\": \"@alpinejs/docs\",\n \"version\": \"3.17.5\",\n \"description\": \"The documentation for Alpine\",\n \"repository\": {\n \"type\": \"git\",\n \"url\": \"https://github.com/alpinejs/alpine.git\",\n \"directory\": \"packages/docs\"\n },\n \"author\": \"Caleb Porzio\",\n \"license\": \"MIT\"\n}\n","packages/docs/src/en/advanced.md":"---\norder: 8\ntitle: Advanced\ntype: sub-directory\n---\n","packages/docs/src/en/advanced/async.md":"---\norder: 4\ntitle: Async\n---\n\n# Async\n\nAlpine is built to support asynchronous functions in most places it supports standard ones.\n\nFor example, let's say you have a simple function called `getLabel()` that you use as the input to an `x-text` directive:\n\n```js\nfunction getLabel() {\n return 'Hello World!'\n}\n```\n```alpine\n\n```\n\nBecause `getLabel` is synchronous, everything works as expected.\n\nNow let's pretend that `getLabel` makes a network request to retrieve the label and can't return one instantaneously (asynchronous). By making `getLabel` an async function, you can call it from Alpine using JavaScript's `await` syntax.\n\n```js\nasync function getLabel() {\n let response = await fetch('/api/label')\n\n return await response.text()\n}\n```\n```alpine\n\n```\n\nAdditionally, if you prefer calling methods in Alpine without the trailing parenthesis, you can leave them out and Alpine will detect that the provided function is async and handle it accordingly. For example:\n\n```alpine\n\n```\n","packages/docs/src/en/advanced/csp.md":"---\norder: 1\ntitle: CSP\n---\n\n# CSP (Content-Security Policy) Build\n\nIn order for Alpine to execute JavaScript expressions from HTML attributes like `x-on:click=\"console.log()\"`, it needs to use utilities that violate the \"unsafe-eval\" [Content Security Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP) that some applications enforce for security purposes.\n\n> Under the hood, Alpine doesn't actually use eval() itself because it's slow and problematic. Instead it uses Function declarations, which are much better, but still violate \"unsafe-eval\".\n\nAlpine offers an alternate build that doesn't violate \"unsafe-eval\" and supports most of Alpine's inline expression syntax.\n\n\n## Installation\n\nYou can use this build by either including it from a `\n```\n\n### Via NPM\n\nYou can alternatively install this build from NPM for use inside your bundle like so:\n\n```shell\nnpm install @alpinejs/csp\n```\n\nThen initialize it from your bundle:\n\n```js\nimport Alpine from '@alpinejs/csp'\n\nwindow.Alpine = Alpine\n\nAlpine.start()\n```\n\n\n## Basic Example\n\nHere's a working counter component using Alpine's CSP build. Notice how most expressions work exactly like regular Alpine:\n\n```alpine\n\n \n \n \n \n \n
\n \n \n\n \n \n 5\">Count is greater than 5!\n
\n \n\n```\n\n\n## What's Supported\n\nThe CSP build supports most JavaScript expressions you'd want to use in Alpine:\n\n### Object and Array Literals\n```alpine\n\n
\n \n \n
\n```\n\n### Basic Operations\n```alpine\n\n
\n \n 3\">\n \n \n
0\">
\n
\n```\n\n### Assignments and Updates\n```alpine\n\n
\n \n \n \n
\n```\n\n### Method Calls\n```alpine\n\n
\n \n
\n```\n\n\n## What's Not Supported\n\nSome advanced and potentially dangerous JavaScript features aren't supported:\n\n### Complex Expressions\n```alpine\n\n
\n \n \n\n \n \n\n \n
Bad
\n\n \n
Bad
\n\n \n
Bad
\n
\n```\n\n### Global Variables and Functions\n```alpine\n\n
\n \n \n \n \n \n \n
\n```\n\n### HTML Injection\n```alpine\n\n
World' }\">\n \n \n
\n```\n\n\n## When to Extract Logic\n\nWhile the CSP build supports simple inline expressions, you'll want to extract complex logic into dedicated functions or Alpine.data() components for better organization:\n\n```alpine\n\n
u.active && u.role === 'admin').length > 0\">\n```\n\n```alpine\n\n
\n\n\n```\n\nThis approach makes your code more readable, testable, and maintainable, especially for complex applications.\n\n\n## CSP Headers\n\nHere's an example CSP header that works with Alpine's CSP build:\n\n```\nContent-Security-Policy: default-src 'self'; script-src 'nonce-[random]' 'strict-dynamic';\n```\n\nThe key is removing `'unsafe-eval'` from your `script-src` directive while still allowing your nonce-based scripts to run.","packages/docs/src/en/advanced/extending.md":"---\norder: 3\ntitle: Extending\n---\n\n# Extending\n\nAlpine has a very open codebase that allows for extension in a number of ways. In fact, every available directive and magic in Alpine itself uses these exact APIs. In theory you could rebuild all of Alpine's functionality using them yourself.\n\n\n## Lifecycle concerns\nBefore we dive into each individual API, let's first talk about where in your codebase you should consume these APIs.\n\nBecause these APIs have an impact on how Alpine initializes the page, they must be registered AFTER Alpine is downloaded and available on the page, but BEFORE it has initialized the page itself.\n\nThere are two different techniques depending on if you are importing Alpine into a bundle, or including it directly via a `\n\n
\n\n \n\n```\n\nIf you want to extract your extension code into an external file, you will need to make sure that file's `\n \n\n
\n\n```\n\n\n### Via an NPM module\n\nIf you imported Alpine into a bundle, you have to make sure you are registering any extension code IN BETWEEN when you import the `Alpine` global object, and when you initialize Alpine by calling `Alpine.start()`. For example:\n\n```js\nimport Alpine from 'alpinejs'\n\nAlpine.directive('foo', ...)\n\nwindow.Alpine = Alpine\nwindow.Alpine.start()\n```\n\nNow that we know where to use these extension APIs, let's look more closely at how to use each one:\n\n\n## Custom directives\n\nAlpine allows you to register your own custom directives using the `Alpine.directive()` API.\n\n\n### Method Signature\n\n```js\nAlpine.directive('[name]', (el, { value, modifiers, expression }, { Alpine, effect, cleanup }) => {})\n```\n\n  |  \n---|---\nname | The name of the directive. The name \"foo\" for example would be consumed as `x-foo`\nel | The DOM element the directive is added to\nvalue | If provided, the part of the directive after a colon. Ex: `'bar'` in `x-foo:bar`\nmodifiers | An array of dot-separated trailing additions to the directive. Ex: `['baz', 'lob']` from `x-foo.baz.lob`\nexpression | The attribute value portion of the directive. Ex: `law` from `x-foo=\"law\"`\nAlpine | The Alpine global object\neffect | A function to create reactive effects that will auto-cleanup after this directive is removed from the DOM\ncleanup | A function you can pass bespoke callbacks to that will run when this directive is removed from the DOM\n\n\n### Simple Example\n\nHere's an example of a simple directive we're going to create called: `x-uppercase`:\n\n```js\nAlpine.directive('uppercase', el => {\n el.textContent = el.textContent.toUpperCase()\n})\n```\n```alpine\n
\n Hello World!\n
\n```\n\n\n### Evaluating expressions\n\nWhen registering a custom directive, you may want to evaluate a user-supplied JavaScript expression:\n\nFor example, let's say you wanted to create a custom directive as a shortcut to `console.log()`. Something like:\n\n```alpine\n
\n
\n
\n```\n\nYou need to retrieve the actual value of `message` by evaluating it as a JavaScript expression with the `x-data` scope.\n\nFortunately, Alpine exposes its system for evaluating JavaScript expressions with an `evaluate()` API. Here's an example:\n\n```js\nAlpine.directive('log', (el, { expression }, { evaluate }) => {\n // expression === 'message'\n\n console.log(\n evaluate(expression)\n )\n})\n```\n\nNow, when Alpine initializes the `
`, it will retrieve the expression passed into the directive (\"message\" in this case), and evaluate it in the context of the current element's Alpine component scope.\n\n\n### Introducing reactivity\n\nBuilding on the `x-log` example from before, let's say we wanted `x-log` to log the value of `message` and also log it if the value changes.\n\nGiven the following template:\n\n```alpine\n
\n
\n\n \n
\n```\n\nWe want \"Hello World!\" to be logged initially, then we want \"yolo\" to be logged after pressing the `\n```\n\nNow that accessing `$clipboard` returns a function itself, we can immediately call it and pass it an argument like we see in the template with `$clipboard('hello world')`.\n\nYou can use the more brief syntax (a double arrow function) for returning a function from a function if you'd prefer:\n\n```js\nAlpine.magic('clipboard', () => subject => {\n navigator.clipboard.writeText(subject)\n})\n```\n\n\n## Writing and sharing plugins\n\nBy now you should see how friendly and simple it is to register your own custom directives and magics in your application, but what about sharing that functionality with others via an NPM package or something?\n\nYou can get started quickly with Alpine's official \"plugin-blueprint\" package. It's as simple as cloning the repository and running `npm install && npm run build` to get a plugin authored.\n\nFor demonstration purposes, let's create a pretend Alpine plugin from scratch called `Foo` that includes both a directive (`x-foo`) and a magic (`$foo`).\n\nWe'll start producing this plugin for consumption as a simple `\n \n\n
\n \n
\n\n```\n\nNotice how our script is included BEFORE Alpine itself. This is important, otherwise, Alpine would have already been initialized by the time our plugin got loaded.\n\nNow let's look inside of `/js/foo.js`'s contents:\n\n```js\ndocument.addEventListener('alpine:init', () => {\n window.Alpine.directive('foo', ...)\n\n window.Alpine.magic('foo', ...)\n})\n```\n\nThat's it! Authoring a plugin for inclusion via a script tag is extremely simple with Alpine.\n\n\n### Bundle module\n\nNow let's say you wanted to author a plugin that someone could install via NPM and include into their bundle.\n\nLike the last example, we'll walk through this in reverse, starting with what it will look like to consume this plugin:\n\n```js\nimport Alpine from 'alpinejs'\n\nimport foo from 'foo'\nAlpine.plugin(foo)\n\nwindow.Alpine = Alpine\nwindow.Alpine.start()\n```\n\nYou'll notice a new API here: `Alpine.plugin()`. This is a convenience method Alpine exposes to prevent consumers of your plugin from having to register multiple different directives and magics themselves.\n\nNow let's look at the source of the plugin and what gets exported from `foo`:\n\n```js\nexport default function (Alpine) {\n Alpine.directive('foo', ...)\n Alpine.magic('foo', ...)\n}\n```\n\nYou'll see that `Alpine.plugin` is incredibly simple. It accepts a callback and immediately invokes it while providing the `Alpine` global as a parameter for use inside of it.\n\nThen you can go about extending Alpine as you please.\n\n\n## Deferring initialization\n\nAlpine initializes a tree of elements synchronously. Integrations that load JavaScript for a component asynchronously — a script module that registers an `Alpine.data()` provider, for example — can lose that race: Alpine evaluates `x-data=\"someComponent\"` before the registration exists.\n\n`Alpine.deferInit(el, promise)` suspends initialization of one element's tree until a promise settles. Nothing inside the tree initializes while it's suspended: directives don't evaluate, nodes added inside it wait, and attribute changes are held and replayed when the tree resumes. The rest of the page initializes normally.\n\n```js\nAlpine.interceptInit(el => {\n if (el.hasAttribute('data-widget') && ! widgetIsLoaded(el)) {\n Alpine.deferInit(el, loadWidget(el))\n }\n})\n```\n\n(`Alpine.interceptInit()` is Alpine's low-level integration hook — its callback runs for every element just before that element initializes.)\n\nA few things to know about the contract:\n\n- Registering must happen synchronously — from an `Alpine.interceptInit()` callback before the element initializes, or on an already-initialized element to suspend future activity in its tree (a morph that's about to bring in new markup, for example).\n- Calling `deferInit()` on the same element again before it resumes adds another prerequisite: the tree initializes after every registered promise settles.\n- A rejected promise is reported through Alpine's error handler, then the tree initializes anyway — a failed prerequisite never leaves a tree permanently suspended.\n- If the element has left the DOM by the time the promise settles, nothing happens. If it re-enters later, it initializes like any other added node.\n- When a suspended tree resumes, init interceptors run again for elements that hadn't initialized yet. Only defer while your prerequisite is still outstanding — like the `widgetIsLoaded()` check above — so the resume pass initializes normally instead of suspending again.\n- `[x-cloak]` attributes inside a suspended tree stay in place until it resumes, so the existing cloaking pattern hides not-yet-ready content.\n- `alpine:initialized` does not wait for suspended trees — it fires when the synchronous pass over the page completes.\n- The promise is expected to settle. A prerequisite that never settles leaves its tree suspended indefinitely — put timeouts on operations that need them before handing the promise to Alpine.\n","packages/docs/src/en/advanced/reactivity.md":"---\norder: 2\ntitle: Reactivity\n---\n\n# Reactivity\n\nAlpine is \"reactive\" in the sense that when you change a piece of data, everything that depends on that data \"reacts\" automatically to that change.\n\nEvery bit of reactivity that takes place in Alpine, happens because of two very important reactive functions in Alpine's core: `Alpine.reactive()`, and `Alpine.effect()`.\n\n> Alpine uses VueJS's reactivity engine under the hood to provide these functions.\n> [→ Browse the @vue/reactivity source](https://github.com/vuejs/core/tree/main/packages/reactivity)\n\nUnderstanding these two functions will give you super powers as an Alpine developer, but also just as a web developer in general.\n\n\n## Alpine.reactive()\n\nLet's first look at `Alpine.reactive()`. This function accepts a JavaScript object as its parameter and returns a \"reactive\" version of that object. For example:\n\n```js\nlet data = { count: 1 }\n\nlet reactiveData = Alpine.reactive(data)\n```\n\nUnder the hood, when `Alpine.reactive` receives `data`, it wraps it inside a custom JavaScript proxy.\n\nA proxy is a special kind of object in JavaScript that can intercept \"get\" and \"set\" calls to a JavaScript object.\n\n[→ Read more about JavaScript proxies](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy)\n\nAt face value, `reactiveData` should behave exactly like `data`. For example:\n\n```js\nconsole.log(data.count) // 1\nconsole.log(reactiveData.count) // 1\n\nreactiveData.count = 2\n\nconsole.log(data.count) // 2\nconsole.log(reactiveData.count) // 2\n```\n\nWhat you see here is that because `reactiveData` is a thin wrapper around `data`, any attempts to get or set a property will behave exactly as if you had interacted with `data` directly.\n\nThe main difference here is that any time you modify or retrieve (get or set) a value from `reactiveData`, Alpine is aware of it and can execute any other logic that depends on this data.\n\n`Alpine.reactive` is only the first half of the story. `Alpine.effect` is the other half, let's dig in.\n\n\n## Alpine.effect()\n\n`Alpine.effect` accepts a single callback function. As soon as `Alpine.effect` is called, it runs the provided function and watches for reads from reactive data. Each reactive property read during that execution becomes a dependency. When one of those properties changes later, Alpine runs the callback again. For example:\n\n```js\nlet data = Alpine.reactive({ count: 1 })\n\nAlpine.effect(() => {\n console.log(data.count)\n})\n```\n\nWhen this code is first run, \"1\" will be logged to the console. Any time `data.count` changes, its value will be logged to the console again.\n\nThis is the mechanism that unlocks all of the reactivity at the core of Alpine.\n\n### How dependency tracking works\n\nDependency collection happens while the effect callback is running. Reading `data.count` inside the callback registers that property with the effect. Changing `data.count` later notifies the effect, which runs again and collects the dependencies used by that execution.\n\nReads made after the callback has returned, such as inside a `setTimeout` callback, are not automatically tracked by the original effect.\n\nAlpine delegates this behavior to Vue's reactivity package. For a deeper explanation of the proxy, dependency-map, and `track`/`trigger` model, see [Vue's reactivity internals](https://frontendatlas.com/vue/trivia/vue-reactivity-system).\n\nTo connect the dots further, let's look at a simple \"counter\" component example without using Alpine syntax at all, only using `Alpine.reactive` and `Alpine.effect`:\n\n```alpine\n\n\nCount: \n```\n```js\nlet button = document.querySelector('button')\nlet span = document.querySelector('span')\n\nlet data = Alpine.reactive({ count: 1 })\n\nAlpine.effect(() => {\n span.textContent = data.count\n})\n\nbutton.addEventListener('click', () => {\n data.count = data.count + 1\n})\n```\n\n\n
\n \n\n
Count:
\n
\n\n\nAs you can see, you can make any data reactive, and you can also wrap any functionality in `Alpine.effect`.\n\nThis combination unlocks an incredibly powerful programming paradigm for web development. Run wild and free.\n","packages/docs/src/en/directives.md":"---\norder: 4\ntitle: Directives\nprefix: x-\nfont-type: mono\ntype: sub-directory\n---\n","packages/docs/src/en/directives/bind.md":"---\norder: 4\ntitle: bind\n---\n\n# x-bind\n\n`x-bind` allows you to set HTML attributes on elements based on the result of JavaScript expressions.\n\nFor example, here's a component where we will use `x-bind` to set the placeholder value of an input.\n\n```alpine\n
\n \n
\n```\n\n\n## Shorthand syntax\n\nIf `x-bind:` is too verbose for your liking, you can use the shorthand: `:`. For example, here is the same input element as above, but refactored to use the shorthand syntax.\n\n```alpine\n\n```\n\n> Despite not being included in the above snippet, `x-bind` cannot be used if no parent element has `x-data` defined. [→ Read more about `x-data`](/directives/data)\n\n\n## Binding classes\n\n`x-bind` is most often useful for setting specific classes on an element based on your Alpine state.\n\nHere's a simple example of a simple dropdown toggle, but instead of using `x-show`, we'll use a \"hidden\" class to toggle an element.\n\n```alpine\n
\n \n\n
\n Dropdown Contents...\n
\n
\n```\n\nNow, when `open` is `false`, the \"hidden\" class will be added to the dropdown.\n\n\n### Shorthand conditionals\n\nIn cases like these, if you prefer a less verbose syntax you can use JavaScript's short-circuit evaluation instead of standard conditionals:\n\n```alpine\n
\n\n
\n```\n\nThe inverse is also available to you. Suppose instead of `open`, we use a variable with the opposite value: `closed`.\n\n```alpine\n
\n\n
\n```\n\n\n### Class object syntax\n\nAlpine offers an additional syntax for toggling classes if you prefer. By passing a JavaScript object where the classes are the keys and booleans are the values, Alpine will know which classes to apply and which to remove. For example:\n\n```alpine\n
\n```\n\nThis technique offers a unique advantage to other methods. When using object-syntax, Alpine will NOT preserve original classes applied to an element's `class` attribute.\n\nFor example, if you wanted to apply the \"hidden\" class to an element before Alpine loads, AND use Alpine to toggle its existence you can only achieve that behavior using object-syntax:\n\n```alpine\n
\n```\n\nIn case that confused you, let's dig deeper into how Alpine handles `x-bind:class` differently than other attributes.\n\n\n### Special behavior\n\n`x-bind:class` behaves differently than other attributes under the hood.\n\nConsider the following case.\n\n```alpine\n
\n```\n\nIf \"class\" were any other attribute, the `:class` binding would overwrite any existing class attribute, causing `opacity-50` to be overwritten by either `hidden` or `''`.\n\nHowever, Alpine treats `class` bindings differently. It's smart enough to preserve existing classes on an element.\n\nFor example, if `hide` is true, the above example will result in the following DOM element:\n\n```alpine\n
\n```\n\nIf `hide` is false, the DOM element will look like:\n\n```alpine\n
\n```\n\nThis behavior should be invisible and intuitive to most users, but it is worth mentioning explicitly for the inquiring developer or any special cases that might crop up.\n\n\n## Binding styles\n\nSimilar to the special syntax for binding classes with JavaScript objects, Alpine also offers an object-based syntax for binding `style` attributes.\n\nJust like the class objects, this syntax is entirely optional. Only use it if it affords you some advantage.\n\n```alpine\n
\n\n\n
\n```\n\nConditional inline styling is possible using expressions just like with x-bind:class. Short circuit operators can be used here as well by using a styles object as the second operand.\n```alpine\n
\n\n\n
\n```\n\nOne advantage of this approach is being able to mix it in with existing styles on an element:\n\n```alpine\n
\n\n\n
\n```\n\nAnd like most expressions in Alpine, you can always use the result of a JavaScript expression as the reference:\n\n```alpine\n
\n
\n
\n\n\n
\n
\n
\n```\n\n\n## Binding Alpine Directives Directly\n\n`x-bind` allows you to bind an object of different directives and attributes to an element.\n\nThe object keys can be anything you would normally write as an attribute name in Alpine. This includes Alpine directives and modifiers, but also plain HTML attributes. The object values are either plain strings, or in the case of dynamic Alpine directives, callbacks to be evaluated by Alpine.\n\n```alpine\n
\n \n\n Dropdown Contents\n
\n\n\n```\n\nThere are a couple of caveats to this usage of `x-bind`:\n\n> When the directive being \"bound\" or \"applied\" is `x-for`, you should return a normal expression string from the callback. For example: `['x-for']() { return 'item in items' }`\n","packages/docs/src/en/directives/cloak.md":"---\norder: 12\ntitle: cloak\n---\n\n# x-cloak\n\nSometimes, when you're using AlpineJS for a part of your template, there is a \"blip\" where you might see your uninitialized template after the page loads, but before Alpine loads.\n\n`x-cloak` addresses this scenario by hiding the element it's attached to until Alpine is fully loaded on the page.\n\nFor `x-cloak` to work however, you must add the following CSS to the page.\n\n```css\n[x-cloak] { display: none !important; }\n```\n\nThe following example will hide the `` tag until its `x-show` is specifically set to true, preventing any \"blip\" of the hidden element onto screen as Alpine loads.\n\n```alpine\nThis will not 'blip' onto screen at any point\n```\n\n`x-cloak` doesn't just work on elements hidden by `x-show` or `x-if`: it also ensures that elements containing data are hidden until the data is correctly set. The following example will hide the `` tag until Alpine has set its text content to the `message` property.\n\n```alpine\n\n```\n\nWhen Alpine loads on the page, it removes all `x-cloak` property from the element, which also removes the `display: none;` applied by CSS, therefore showing the element.\n\n## Alternative to global syntax\n\nIf you'd like to achieve this same behavior, but avoid having to include a global style, you can use the following cool, but admittedly odd trick:\n\n```alpine\n\n```\n\nThis will achieve the same goal as `x-cloak` by just leveraging the way `x-if` works.\n\nBecause `