-
-
Notifications
You must be signed in to change notification settings - Fork 328
build: migrate CI/CD to Nix-based development environment #747
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Introduce Nix-based development environment to standardise tooling across contributors and CI systems. This replaces manual installation of development tools with declarative package management. The flake provides: - pnpm 10 for package management - typos for spell checking - jq, git, gh for CI/development workflows - Automatic pnpm dependency installation via shellHook Added direnv integration (.envrc) for automatic environment activation when entering the project directory. Updated .gitignore to exclude direnv cache whilst preserving .envrc configuration. This change enables CI migration from setup-pnpm to Nix whilst maintaining consistent tool versions between local and CI environments.
Create composite GitHub Action for installing Nix and configuring Cachix binary caches. This action standardises Nix setup across all CI workflows with consistent versioning and cache configuration. The action installs: - Nix via cachix/install-nix-action@v31.8.4 - numtide Cachix for community binary cache - ryoppippi Cachix (optional, based on token presence) This composite action enables workflow reuse and ensures all CI jobs use identical Nix installation and cache configuration, improving build reproducibility and reducing setup code duplication.
Replace pnpm/action-setup with Nix-based tooling across all CI jobs. This change ensures consistent tool versions between local development and CI by using the same Nix flake environment. Changes per job: - lint-check: Use nix develop for linting and type checking - test: Use nix develop for test execution - npm-publish-dry-run: Use nix develop for pkg-pr-new - spell-check: Replace crate-ci/typos action with Nix typos command - schema-check: Use nix develop for schema generation All jobs migrated from ubuntu-slim to ubuntu-24.04-arm runners to support Nix installation. This migration eliminates pnpm installation step and leverages Cachix for faster builds via binary caches. Removed jq availability check from test job since jq is now provided by the Nix flake environment. The Nix environment provides jq, git, gh, typos, and pnpm with versions defined in flake.lock, ensuring reproducible CI builds.
Replace pnpm/action-setup with Nix-based tooling in npm publishing workflow whilst preserving actions/setup-node for NPM registry authentication. This maintains provenance publishing capabilities whilst adopting Nix for consistent tooling. Changes: - npm job: Replace pnpm/action-setup with setup-nix action - npm job: Migrate from ubuntu-slim to ubuntu-24.04-arm for Nix support - npm job: Execute pnpm publish via nix develop command - release job: Migrate from ubuntu-slim to ubuntu-24.04-arm - Preserve actions/setup-node for registry-url and NPM authentication The setup-node step remains essential for: - Setting NPM_CONFIG_PROVENANCE=true for provenance publishing - Configuring NODE_AUTH_TOKEN for registry authentication - Enabling --provenance flag in pnpm publish command This migration ensures release builds use identical tooling versions to development and CI via the Nix flake environment.
Add pkg-pr-new and changelogithub as managed dependencies in the pnpm catalog under the release category. This replaces the previous approach of using bunx/pnpm dlx with pinned versions in CI workflows. Changes: - Added pkg-pr-new@^0.0.60 to release catalog in pnpm-workspace.yaml - Added changelogithub@^13.16.0 to release catalog - Installed both packages in root devDependencies via catalog references Managing these tools through pnpm provides several benefits: - Version consistency across local development and CI - Faster CI execution via lockfile-based installation - Eliminates need for bunx runtime in release workflow - Enables usage through Nix development environment - Centralised version management in pnpm catalog These tools will be invoked via `pnpm pkg-pr-new` and `pnpm changelogithub` commands in CI workflows.
Replace bunx and pnpm dlx invocations with pnpm-managed package commands for pkg-pr-new and changelogithub. This leverages the dependencies added to the pnpm catalog and executed via Nix development environment. Changes to CI workflow: - npm-publish-dry-run: Changed from `pnpm dlx pkg-pr-new@0.0.60` to `pnpm pkg-pr-new`, using catalog-managed version Changes to release workflow: - release job: Replaced `bunx changelogithub@13.16.0` with `pnpm changelogithub`, using catalog-managed version - release job: Replaced oven-sh/setup-bun action with setup-nix action to access pnpm via Nix environment Benefits: - Eliminates Bun runtime dependency in release workflow - Removes version pinning from workflow files - Faster execution via pre-installed dependencies from lockfile - Consistent tool versions with local development environment - Single source of truth for versions in pnpm-workspace.yaml Both commands execute within `nix develop` to access the pnpm installation and project dependencies from the Nix flake environment.
Add documentation for Nix-based development environment setup in the ccusage package README. This provides contributors with clear instructions for setting up a consistent development environment using the Nix flake. The setup instructions are positioned after the Documentation section and before Sponsors, providing: - Repository cloning instructions - direnv automatic environment activation - Manual nix develop shell entry This addition helps contributors understand how to leverage the Nix flake environment for a consistent development experience across different machines and operating systems.
Update GitHub Actions dependencies to their latest versions using pinact for improved security and features. Updates: - actions/checkout: v5.0.1 → v6.0.1 - actions/setup-node: v5.0.0 → v6.1.0 - cachix/install-nix-action: v31.8.4 → v31.9.0 These updates ensure the CI pipeline uses the latest stable versions of GitHub Actions with recent bug fixes and security improvements.
|
Caution Review failedThe pull request is closed. WalkthroughAdds Nix-based developer environment (flake.nix, .envrc), updates .gitignore, introduces a composite GitHub Action to install Nix and configure Cachix, and converts CI/release workflows to run commands via Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant GH as GitHub Actions
participant Setup as .github/actions/setup-nix
participant Cachix as Cachix Action(s)
participant Shell as nix develop
participant Runner as Job Runner
GH->>Setup: invoke setup-nix (inputs: cachix-auth-token?)
Setup->>Runner: install Nix (cachix/install-nix-action)
Setup->>Cachix: configure cachix for `numtide` (no token)
alt auth token provided
Setup->>Cachix: configure cachix for `ryoppippi` (with token)
end
GH->>Shell: run `nix develop --command pnpm ...` (lint/test/publish)
Shell->>Runner: spawn pnpm commands inside Nix devShell
Runner->>GH: job completes (success/failure)
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes
Possibly related PRs
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ✅ Deployment successful! View logs |
ccusage-guide | 41ac8cd | Dec 11 2025, 05:27 PM |
commit: |
Add `nix develop --command true` step to setup-nix action to preload the Nix development environment and cache all dependencies. This ensures subsequent `nix develop --command` invocations in workflow steps start instantly without waiting for environment initialisation. Benefits: - Faster workflow execution by avoiding repeated environment setup - Explicit environment validation at setup stage - Better error reporting if Nix environment fails to load - Dependencies downloaded once and cached for all subsequent steps This change reduces total CI time by eliminating redundant Nix environment initialisation in each workflow step.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/ci.yaml (1)
50-57: Update error message to reflect Nix-based workflow.Line 57 directs users to run
pnpm run generate:schemadirectly, but the workflow usesnix develop --command pnpm run generate:schema. Update the error message for consistency and clarity on how developers should regenerate schemas locally.- echo "❌ Schema files are not up-to-date. Please run 'pnpm run generate:schema' and commit the changes." + echo "❌ Schema files are not up-to-date. Please run 'nix develop -- pnpm run generate:schema' in apps/ccusage and commit the changes."
🧹 Nitpick comments (2)
.github/actions/setup-nix/action.yaml (1)
13-13: Consider passing github.token as an input parameter.Currently, the action directly references
${{ github.token }}, which works in composite actions but makes the action less flexible. Consider acceptinggithub-tokenas an input parameter with a default value for better reusability.Apply this diff to make the token configurable:
+ github-token: + description: GitHub token for Nix installation + required: false + default: ${{ github.token }} cachix-auth-token: description: Cachix authentication token required: false @@ -10,7 +13,7 @@ - name: Install Nix uses: cachix/install-nix-action@4e002c8ec80594ecd40e759629461e26c8abed15 # v31.9.0 with: - github_access_token: ${{ github.token }} + github_access_token: ${{ inputs.github-token }}flake.nix (1)
5-5: Consider using a stable nixpkgs channel for CI reproducibility.Using
nixpkgs-unstableprovides the latest packages but may introduce unexpected changes in CI. For production CI/CD workflows, consider using a stable nixpkgs release (e.g.,nixos-24.11) or pinning to a specific commit for better reproducibility.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (2)
flake.lockis excluded by!**/*.lockpnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (9)
.envrc(1 hunks).github/actions/setup-nix/action.yaml(1 hunks).github/workflows/ci.yaml(1 hunks).github/workflows/release.yaml(1 hunks).gitignore(1 hunks)apps/ccusage/README.md(1 hunks)flake.nix(1 hunks)package.json(1 hunks)pnpm-workspace.yaml(1 hunks)
🧰 Additional context used
📓 Path-based instructions (3)
**/*.{ts,tsx,json}
📄 CodeRabbit inference engine (CLAUDE.md)
Claude model naming convention:
claude-{model-type}-{generation}-{date}(e.g.,claude-sonnet-4-20250514, NOTclaude-4-sonnet-20250514)
Files:
package.json
**/package.json
📄 CodeRabbit inference engine (CLAUDE.md)
Dependencies should always be added as devDependencies unless explicitly requested otherwise
Files:
package.json
**/*.md
📄 CodeRabbit inference engine (CLAUDE.md)
**/*.md: Place screenshots immediately after the main heading (H1) in documentation pages for immediate visual context
Use relative image paths like/screenshot.pngfor images stored in/docs/public/in documentation
Always include descriptive alt text for images in documentation for accessibility
Files:
apps/ccusage/README.md
🧠 Learnings (9)
📚 Learning: 2025-09-17T18:29:15.764Z
Learnt from: CR
Repo: ryoppippi/ccusage PR: 0
File: apps/mcp/CLAUDE.md:0-0
Timestamp: 2025-09-17T18:29:15.764Z
Learning: Applies to apps/mcp/**/package.json : Add new dependencies as `devDependencies` unless explicitly requested otherwise
Applied to files:
package.json
📚 Learning: 2025-09-18T16:06:37.474Z
Learnt from: CR
Repo: ryoppippi/ccusage PR: 0
File: apps/ccusage/CLAUDE.md:0-0
Timestamp: 2025-09-18T16:06:37.474Z
Learning: Applies to apps/ccusage/**/package.json : Add dependencies as devDependencies unless explicitly required otherwise
Applied to files:
package.jsonapps/ccusage/README.md
📚 Learning: 2025-11-25T14:42:34.734Z
Learnt from: CR
Repo: ryoppippi/ccusage PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T14:42:34.734Z
Learning: Applies to **/package.json : Dependencies should always be added as devDependencies unless explicitly requested otherwise
Applied to files:
package.json
📚 Learning: 2025-09-18T16:07:16.293Z
Learnt from: CR
Repo: ryoppippi/ccusage PR: 0
File: apps/codex/CLAUDE.md:0-0
Timestamp: 2025-09-18T16:07:16.293Z
Learning: Applies to apps/codex/**/package.json : Package Codex as a bundled CLI and keep every runtime dependency in devDependencies so the bundle includes shipped code
Applied to files:
package.json
📚 Learning: 2025-09-18T16:06:37.474Z
Learnt from: CR
Repo: ryoppippi/ccusage PR: 0
File: apps/ccusage/CLAUDE.md:0-0
Timestamp: 2025-09-18T16:06:37.474Z
Learning: Applies to apps/ccusage/**/package.json : Because the CLI is bundled, keep all runtime libraries in devDependencies so the bundler captures them
Applied to files:
package.json
📚 Learning: 2025-11-25T14:42:34.734Z
Learnt from: CR
Repo: ryoppippi/ccusage PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T14:42:34.734Z
Learning: Refer to individual CLAUDE.md files in apps/ccusage/CLAUDE.md, apps/mcp/CLAUDE.md, and docs/CLAUDE.md for package-specific guidance
Applied to files:
apps/ccusage/README.mdflake.nix.github/workflows/ci.yaml
📚 Learning: 2025-09-18T16:06:37.474Z
Learnt from: CR
Repo: ryoppippi/ccusage PR: 0
File: apps/ccusage/CLAUDE.md:0-0
Timestamp: 2025-09-18T16:06:37.474Z
Learning: After any code change, run format, typecheck, and tests in parallel (`pnpm run format`, `pnpm typecheck`, `pnpm run test`)
Applied to files:
.github/workflows/ci.yaml
📚 Learning: 2025-11-25T14:42:34.734Z
Learnt from: CR
Repo: ryoppippi/ccusage PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T14:42:34.734Z
Learning: After making any code changes, run `pnpm run format`, `pnpm typecheck`, and `pnpm run test` in parallel
Applied to files:
.github/workflows/ci.yaml
📚 Learning: 2025-09-17T18:29:15.764Z
Learnt from: CR
Repo: ryoppippi/ccusage PR: 0
File: apps/mcp/CLAUDE.md:0-0
Timestamp: 2025-09-17T18:29:15.764Z
Learning: After code changes, always run `pnpm run format`, `pnpm typecheck`, and `pnpm run test` in parallel
Applied to files:
.github/workflows/ci.yaml
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: lint-check
- GitHub Check: Workers Builds: ccusage-guide
🔇 Additional comments (9)
package.json (1)
33-33: LGTM!The new release tooling packages are correctly added as
devDependenciesand properly mapped to the release catalog. Based on learnings, this follows the project convention of adding dependencies as devDependencies unless explicitly required otherwise.Also applies to: 37-37
apps/ccusage/README.md (1)
151-169: LGTM!The development setup documentation is clear and provides helpful instructions for contributors using the new Nix-based environment.
flake.nix (1)
27-33: Minor documentation inconsistency: the comment and code direction don't match.The shellHook timestamp comparison logic is syntactically valid and works correctly. However, the inline comment states "Install dependencies only if node_modules/.pnpm/lock.yaml is older than pnpm-lock.yaml" while the condition checks if pnpm-lock.yaml is newer than node_modules/.pnpm/lock.yaml—which are opposite phrasings of the same thing. Update the comment to clarify: "Install dependencies only if node_modules/.pnpm/lock.yaml does not exist or is older than pnpm-lock.yaml" for consistency with the code logic.
.github/workflows/release.yaml (2)
16-16: All action version hashes are correct and match their claimed versions. The commit hash8e8c483db84b4bee98b60c0593521ed34d9990e8foractions/checkout@v6.0.1(lines 16, 33) and395ad3262231945c25e8478fd5baf05154b1d79fforactions/setup-node@v6.1.0(line 20) have been verified against the official GitHub release tags and are accurate.
10-10: Remove verification concern —ubuntu-24.04-armis an officially supported GitHub Actions hosted runner.The
ubuntu-24.04-armrunner is a legitimate GitHub-provided ARM64 hosted runner and is available for public repositories. The original concern about availability is unfounded; this runner is listed in GitHub's official hosted-runners reference and was made generally available.If Nix compatibility is a concern, verify it through workflow testing rather than runner selection, as this is a configuration/dependency issue, not a runner support limitation.
pnpm-workspace.yaml (1)
34-34: The versions specified are already current:changelogithubis at the latest 13.16.0 andpkg-pr-newis at the latest 0.0.60 (as of December 2025)..github/actions/setup-nix/action.yaml (1)
16-19: The commit hash0fc020193b5a1fa3ac4575aa3a7d3aa6a35435adcorrectly corresponds to version v16 ofcachix/cachix-action. No changes needed..github/workflows/ci.yaml (2)
35-35: Verify glob pattern handling in pkg-pr-new publish command.The glob
'./apps/*'is single-quoted, which prevents shell expansion and passes the literal string to pnpm. Confirm thatpnpm pkg-pr-new publish --pnpm './apps/*'correctly handles this literal pattern and expands it as intended (not as an error). If shell expansion is needed, the glob should be unquoted.
12-15: No action required—setup-nix action is properly configured.The
.github/actions/setup-nixaction exists and correctly:
- Initializes the Nix environment via
cachix/install-nix-action@v31.9.0- Configures Cachix for binary caching, with both numtide and ryoppippi caches set up
- Uses pinned commit hashes for security
All nix develop commands in the workflow will work correctly with this setup.
| node-version: lts/* | ||
| - run: pnpm install --frozen-lockfile | ||
| - run: pnpm --filter='./apps/**' publish --provenance --no-git-checks --access public | ||
| - run: nix develop --command pnpm --filter='./apps/**' publish --provenance --no-git-checks --access public |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧩 Analysis chain
🌐 Web query:
actions/setup-node registry-url NODE_AUTH_TOKEN authentication
💡 Result:
Short answer: actions/setup-node writes an .npmrc that reads the auth token from the NODE_AUTH_TOKEN environment variable when you pass registry-url (and optional scope). You must set NODE_AUTH_TOKEN in the workflow’s env (usually from a secret such as NPM_TOKEN or GITHUB_TOKEN). For GitHub Packages you can use GITHUB_TOKEN for packages in the same repo; for other private registries use a personal access token with appropriate scopes. Examples and docs below. [1][2][3]
Example (minimal):
- name: Use Node.js
uses: actions/setup-node@v4
with:
node-version: '20.x'
registry-url: 'https://registry.npmjs.org' # or https://npm.pkg.github.com for GPR - name: Install
run: npm ci
env:
NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }} # or ${{ secrets.GITHUB_TOKEN }} when allowed
What setup-node creates in .npmrc:
//registry.npmjs.org/:_authToken=${NODE_AUTH_TOKEN}
registry=https://registry.npmjs.org/
always-auth=true
References:
[1] actions/setup-node (GitHub repo/docs).
[2] GitHub Actions docs — Use setup-node + example showing NODE_AUTH_TOKEN usage.
[3] GitHub Packages / npm registry auth guidance (GITHUB_TOKEN vs personal access token).
🌐 Web query:
npm publish OIDC provenance GitHub Actions authentication
💡 Result:
Short answer — yes. You can publish npm packages from GitHub Actions using OIDC-based authentication and produce/verifiy provenance. High-level steps and requirements:
- Requirements
- npm CLI: >=9.5.0 to generate/consume provenance; npm >=11.5.1 for npm “trusted publishing” (OIDC-based publishes without static tokens). [1][2]
- Workflow permissions (GitHub Actions)
- Give the job permission to mint an ID token: permissions: id-token: write. Use GitHub-hosted runners (self-hosted not supported for provenance/trusted publishing). [1][2]
- Publish with provenance (older flow or explicit)
- Build on a supported cloud CI runner (GitHub Actions).
- Run npm publish --provenance (and --access public if first public publish). npm will use Sigstore to sign provenance and upload to Rekor; registry verifies provenance on publish. [1][4]
- Trusted publishing (OIDC-backed, recommended)
- Configure a “trusted publisher” in your npm package settings (establishes which workflow file may publish).
- With trusted publishing, the registry accepts short‑lived, workflow-specific credentials issued via OIDC; provenance is produced automatically (no --provenance needed). You can publish without storing long‑lived NPM tokens in secrets. Requires npm CLI v11.5.1+ and cloud runner. [2][5]
- Notes / limitations
- Provenance/trusted publishing currently requires public source repositories for provenance; private repos may not get provenance. Some npm commands (install/view) still need traditional auth for other operations (and private package installs may require a read token). Each package can have one trusted publisher at a time. [1][2][6]
Pointers / docs
- Generating provenance / GitHub Actions example (npm docs). [1]
- Trusted publishing docs (how to configure and limits). [2]
- GitHub Actions npm-publish action notes (supports OIDC if npm version supports trusted publishing). [3]
- npm provenance implementation/details (npm’s provenance repo). [4]
If you want, I can: (A) generate a ready-to‑use GitHub Actions workflow (with permissions, setup-node, npm publish) for your repo and npm version, or (B) walk through configuring a trusted publisher in the npm web UI — which do you want?
🏁 Script executed:
cat -n .github/workflows/release.yamlRepository: ryoppippi/ccusage
Length of output: 1376
🏁 Script executed:
# Check if there's a .npmrc file in the repository that might provide implicit authentication
find . -maxdepth 2 -name ".npmrc" -type fRepository: ryoppippi/ccusage
Length of output: 43
Add explicit NODE_AUTH_TOKEN environment variable for npm publishing.
The workflow configures setup-node with registry-url but does not explicitly set NODE_AUTH_TOKEN. While setup-node creates the .npmrc structure to read authentication from the environment, it requires NODE_AUTH_TOKEN to be explicitly provided in the job's env block. Add NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }} (or equivalent) to the npm job's environment, or alternatively, ensure the npm version (>=11.5.1) supports OIDC-based trusted publishing and configure it in your npm package settings to publish without storing long-lived tokens.
🤖 Prompt for AI Agents
.github/workflows/release.yaml around line 24: the publish step does not set
NODE_AUTH_TOKEN so setup-node cannot populate .npmrc auth; add NODE_AUTH_TOKEN:
${{ secrets.NPM_TOKEN }} to the npm job's env block (or the job that runs the
publish command) so the workflow supplies the token to npm during publish;
alternatively, if you intend to use OIDC-based trusted publishing, configure npm
>=11.5.1 and package settings instead, but the immediate fix is to set
NODE_AUTH_TOKEN from secrets.NPM_TOKEN in the job env.
| buildInputs = with pkgs; [ | ||
| # Package manager | ||
| pnpm_10 | ||
|
|
||
| # Development tools | ||
| typos | ||
| jq | ||
| git | ||
| gh | ||
| ]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Critical: Node.js is missing from buildInputs.
The flake provides pnpm_10 but doesn't include Node.js itself. The package.json specifies Node.js ^24.11.0 in devEngines, but the Nix development shell doesn't provide it. This will cause the development environment and CI workflows to fail since pnpm and the project require Node.js to function.
Apply this diff to add Node.js to buildInputs:
buildInputs = with pkgs; [
+ # Runtime
+ nodejs_24
+
# Package manager
pnpm_10📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| buildInputs = with pkgs; [ | |
| # Package manager | |
| pnpm_10 | |
| # Development tools | |
| typos | |
| jq | |
| git | |
| gh | |
| ]; | |
| buildInputs = with pkgs; [ | |
| # Runtime | |
| nodejs_24 | |
| # Package manager | |
| pnpm_10 | |
| # Development tools | |
| typos | |
| jq | |
| git | |
| gh | |
| ]; |
🤖 Prompt for AI Agents
In flake.nix around lines 16 to 25, buildInputs contains pnpm_10 but omits
Node.js causing pnpm and project tooling to fail; add the appropriate Node.js
package (matching project engine, e.g., nodejs-24_x or nodejs-24) from pkgs to
buildInputs alongside pnpm_10 so the development shell and CI have Node
available; ensure you import it from pkgs (with pkgs; [ nodejs-24_x pnpm_10 ...
]) and run nix flake update/test to verify the environment provides the correct
Node version.
Summary
Migrate the entire CI/CD pipeline from pnpm/action-setup and bunx to a Nix-based development environment, providing consistent tooling across local development and CI systems.
What Changed
flake.nixwith pnpm, typos, jq, git, and gh.envrcfor automatic environment activationWhy
This migration provides several key benefits:
Testing
Summary by CodeRabbit
Chores
Documentation
✏️ Tip: You can customize this high-level summary in your review settings.