Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/hetari/creative-coding/llms.txt

Use this file to discover all available pages before exploring further.

The Creative Coding playground enforces consistent code style and commit hygiene through a three-part toolchain. @antfu/eslint-config provides an opinionated, zero-config ESLint setup that covers TypeScript, Vue 3, and formatting in one package. Husky registers Git hooks, and nano-staged runs ESLint auto-fix on every staged file before a commit is recorded — so style issues are corrected automatically rather than blocking the developer. Finally, Commitlint validates every commit message against the Conventional Commits specification, ensuring the project history stays readable and tooling-friendly.

​
ESLint

​
Configuration

ESLint is configured in eslint.config.js using the @antfu/eslint-config preset with formatters and Vue support enabled: 
import antfu from '@antfu/eslint-config'

export default antfu({
  formatters: true,
  vue: true,
})
The formatters: true option activates eslint-plugin-format, which delegates file formatting (indentation, trailing commas, quote style) to Prettier-compatible rules inside ESLint rather than requiring a separate Prettier process. The vue: true option enables Vue single-file-component parsing and Vue-specific lint rules.

​
Running Lint

Use the following scripts, defined in package.json, to check or fix the entire project: 
bun run lint        # check the entire project and report errors
bun run lint:fix    # auto-fix all fixable formatting and lint errors
Both commands run eslint (or eslint --fix) against all *.{js,ts,vue} files matched by the config. Run lint:fix after any bulk refactor or when onboarding to resolve accumulated style drift in one pass.
@antfu/eslint-config is opinionated by design — it enforces single quotes, no semicolons, consistent import ordering, and other stylistic rules out of the box. You do not need a separate .prettierrc or prettier dependency.

​
Pre-commit Hooks (Husky + nano-staged)

​
How It Works

Husky installs a pre-commit Git hook that fires automatically every time you run git commit. The hook delegates to nano-staged, which reads the "nano-staged" key in package.json and runs the configured command against only the files you have staged — not the entire repository. The pre-commit hook script: 
#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

bunx nano-staged
The nano-staged configuration in package.json: 
"nano-staged": {
  "*.{js,ts,vue}": "eslint --fix"
}
This means:
  1. You stage your changes with git add.
  2. You run git commit.
  3. Husky fires the pre-commit hook.
  4. nano-staged finds every staged *.js, *.ts, or *.vue file and runs eslint --fix on each one in-place.
  5. The auto-fixed versions of those files are included in the commit automatically.
  6. If ESLint encounters an error it cannot fix automatically, the commit is aborted and the error is printed to the terminal.

​
Benefits

Because only staged files are linted, the pre-commit step is fast even in a large workspace. You never need to run bun run lint:fix manually before committing — nano-staged handles it for you.
If a file has both staged and unstaged changes, nano-staged handles the stash/unstash cycle automatically so your unstaged work is not accidentally included in the commit.

​
Commitlint (Conventional Commits)

​
Overview

The commit-msg Husky hook validates every commit message using @commitlint/cli against @commitlint/config-conventional before the commit is finalised. Any message that does not conform to the Conventional Commits format causes the commit to be rejected with a clear error message. The commit-msg hook script: 
#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

bunx --no commitlint --edit "$1"
The commitlint configuration in commitlint.config.js: 
export default {
  extends: ['@commitlint/config-conventional'],
}

​
Conventional Commits Format

Every commit message must follow this structure: 
<type>: <description>
An optional body and footer may follow after a blank line, but the first line must always start with a recognised type, a colon, a space, and then a short imperative description.

​
Valid Commit Types

TypeWhen to use
featA new sketch, feature, or capability
fixA bug fix
docsDocumentation changes only
styleCode style changes that do not affect logic (formatting, whitespace)
refactorCode restructuring that is neither a fix nor a feature
perfA change that improves performance
testAdding or updating tests
buildChanges to the build system or dependencies
ciChanges to CI configuration files or scripts
choreRoutine tasks — dependency bumps, tooling config, etc.
revertReverts a previous commit

​
Valid Commit Message Examples

feat: add ascii rasterizer composable
fix: hide lil-gui in iframe preview
refactor: move sketches to src/sketches/
docs: update quickstart guide
chore: upgrade pixi.js to v8
perf: defer sketch component imports until route is active
build: switch bundler output to es2022 target

​
Invalid Commit Message Examples

The following messages will be rejected by commitlint: 
Added new sketch
WIP
fix stuff
update
These fail because they either lack a type prefix entirely, use an unrecognised type, or omit the colon-space separator.
If your commit is rejected by commitlint, check that your message starts with a recognised type — feat:, fix:, chore:, etc. — followed by a colon, a single space, and a short description in the imperative mood. Running git commit -m "feat: your description here" is the fastest way to get the format right.

​
Setup

Husky and commitlint are already configured and their hook files are committed to the repository under .husky/. No manual setup is required beyond the normal install step. When you run bun install for the first time, the prepare lifecycle script runs automatically: 
bun install   # installs all dependencies, then runs 'husky' via the prepare script

"scripts": {
  "prepare": "husky"
}
This registers the .husky/ hook scripts with your local Git configuration. From that point on, both the pre-commit (nano-staged ESLint fix) and commit-msg (commitlint validation) hooks are active for every commit made in the repository.
If you clone the repository and skip bun install, the hooks will not be registered and neither auto-fix nor commit message validation will run. Always install dependencies before making commits.

Build docs developers (and LLMs) love

Get started for freeTalk to us