jungho-git/javascript

JavaScript

• Shared examples and formatting reference: references/EXAMPLE.md.
• Keep new guidance, snippets, and edits aligned with that file.

---

Scope

Use this rule when:

• editing .js, .jsx, or mixed JavaScript runtime files
• changing props, request shapes, returned data, or state transitions
• touching browser, frontend, Node-compatible, or Bun runtime logic
• adding standalone scripts or runtime entry files

JavaScript changes should preserve real boundaries, state flow, and local style.

---

Runtime

• Run JavaScript with bun, not node, unless the user or project explicitly requires another runner.
• Use bun, bun -e, bun repl, bunx, or bun x instead of node, node -e, or npx.
• Use Bun.file() and Bun.write() for local file processing only when fs-mcp cannot reasonably do the job.
• Do not use PowerShell content built-ins for local file processing.

---

Syntax Rules

• Never use var; use const by default and let only for reassignment.
• Declare variables at the narrowest useful scope.
• Keep adjacent const and let declarations in the same setup block contiguous; do not insert blank lines between them unless a new logical section starts.
• Use template literals for interpolation; do not concatenate strings with + when variables are involved.
• Prefer optional chaining for nullable nested access.
• Never use index-based for loops; prefer for...of, forEach, map, filter, or reduce.
• Prefer arrow functions for callbacks.
• Define regex constants at the smallest function, method, or class scope that uses them.
• When generating new code, keep newly authored constant and variable names at 30 chars or fewer by default; alias external contract names locally when needed.
• Use double-quoted object keys where the file follows JSON-like object style.
• Prefer vanilla JavaScript over jQuery; use jQuery only when already established and replacement is out of scope.

---

Boundary And State Rules

• Check props, request/response shapes, returned data, and state transitions before editing.
• Normalize reused scalar values once near the top of the block.
• Validate at the real data boundary, then use normalized values directly.
• Keep state, rendering, business rules, and data shaping separate unless local code already combines them.
• Preserve async error paths and caller assumptions.

---

Function Shape

• Keep related logic cohesive.
• Extract only for real duplication, unavoidable complexity, a real boundary, or a testable contract.
• Do not split straightforward logic into tiny wrappers.
• Use the comments skill for section divider comments.
• Add a JSDoc file header to standalone scripts when local files use that pattern.

---

Formatting

• Follow Google JavaScript Style where it does not conflict with local style.
• Use Stroustrup clause layout for else, catch, and finally.
• Always use braces for control-flow bodies.
• Prefer early returns to keep the happy path flat.
• When a control-flow condition wraps, keep only the keyword and opening parenthesis on the first line, put one condition per line, keep && or || at the end of continued condition lines, and use ) { as the closing line.
• Use exactly one space around binary operators.
• Never vertically align assignments, object values, or operators.

---

Validation Focus

• input and output shapes
• state transitions
• async error paths
• caller and consumer assumptions
• boundary uncertainty vs stable in-app invariants
• one guard at the contract edge