feat(mise): add setup:npm task so mise run default works from fresh clone#1280
Conversation
- Update Quick Start to use 'mise run default' instead of separate mise install + npm ci - Update NPM Scripts section to reference mise run setup for all npm/tooling setup - Simplify Troubleshooting missing dependencies section to just 'mise run setup' The setup:npm task now handles npm ci automatically, integrated into the full mise task pipeline (default → setup → setup:npm).
Also document setup:npm in DEVELOPING.md task table and project structure.
Without this, mise ran setup and build tasks in parallel. build:check-elm-docs would fail with 'elm not found' because setup:elm-tooling hadn't finished yet. Previously masked by an explicit npm ci CI step that installed elm tooling before mise ran. Now that mise handles npm ci, the ordering must be explicit.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 973e9c5451
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| #!/usr/bin/env bun | ||
| //MISE description="Run all setup tasks" | ||
| //MISE depends=["setup:elm-tooling", "setup:morphir-jvm"] | ||
| //MISE depends=["setup:npm", "setup:elm-tooling", "setup:morphir-jvm"] |
There was a problem hiding this comment.
Adding setup:npm only under the setup aggregate does not make the build branch of mise run default wait for npm dependencies: default.ts still depends on setup and build as independent siblings, and mise run --dry-run default prints build:check-elm-docs before setup:npm. On a fresh clone or in the updated CI workflow where the explicit npm ci step was removed, the build can invoke elm/npx before node_modules/.bin exists, so the default pipeline can still fail instead of becoming self-bootstrapping.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in 4869003 — added //MISE depends=["setup:elm-tooling"] to build:check-elm-docs.ts. All other elm build tasks already chain through build:check-elm-docs, so this single dep propagates the ordering constraint through the full build chain. Also added build:build.ts depends=[setup,...] as an explicit guard, and removed the standalone npm ci CI step that was masking the race.
All other elm build tasks already depend on build:check-elm-docs, so this single dependency propagates the constraint through the entire build chain. Revert build.ts change from previous commit as it was the wrong fix — mise depends siblings run in parallel, so adding setup to build's depends list did not prevent build subtasks from racing against setup.
…est deps Previous approach (adding setup:elm-tooling to build:check-elm-docs) caused test:integration → build:cli → build:check-elm-docs → setup:elm-tooling → setup:npm, which re-ran npm ci during mise run test. npm ci wipes node_modules while test:unit runs elm-test in parallel → MODULE NOT FOUND. Instead: default.ts runs clean/checks/setup via depends (phase 1), then invokes mise run build in the script body (phase 2). Build tasks have no setup dependencies, so mise run test never triggers npm ci.
elm-tooling 1.17.0 adds Windows ARM64 support by pointing at the existing x86_64 binaries (which run under WoW64/Prism emulation), so `setup:elm-tooling` now actually installs elm/elm-format/elm-json/ elm-test-rs shims on win32-arm64 instead of silently skipping them. Also bumps elm-format to 0.8.8 (available since elm-tooling 1.16).
Concurrent elm make processes on a cold ~/.elm package cache cause non-deterministic failures on Windows — elm's package store is not concurrent-write-safe. Fix: - build:cli runs CLI.elm then DevCLI.elm sequentially (same elm.json, would otherwise race on cold cache packages like elm/bytes, elm/file) - build:cli2, build:dev-server, build:try-morphir now depend on build:cli, so the cli/ package cache is fully warm before they start
…1281) * fix(mise): orchestrate elm builds serially to eliminate Windows race When the elm package cache (~/.elm) or per-project elm-stuff/ is cold, multiple concurrent `elm make` invocations race on ~/.elm/<package>/artifacts.dat and the shared elm-stuff/ files, producing the "PROBLEM BUILDING DEPENDENCIES" failure that's been intermittently breaking the Windows CI build (e.g. PR #1280's 26558683076 and 26559185295 runs). Linux mostly avoids it thanks to friendlier file-locking semantics but the underlying race is the same. The previous round of fixes added `//MISE depends=` headers expecting mise to serialize tasks. mise reads those headers but its scheduler parallelizes any tasks whose deps are satisfied — both Linux and Windows CI logs show cli, cli2, dev-server, try-morphir, and treeview starting within ~1ms of each other after check-elm-docs finishes. The recent passing runs were the race coming out the other way, not a real fix. Changes: - .mise/tasks/build.ts: drive the elm-touching tasks via an explicit `mise run --skip-deps <task>` chain (check-elm-docs → cli → cli2 → dev-server → try-morphir → components → morphir-ts). --skip-deps stops each subtask from re-running its own declared deps. treeview (webpack only) runs in parallel alongside the chain. - .mise/tasks/build/dev-server.ts: serialize its three internal elm makes — they all target cli/elm.json, so the same race that motivated the build:cli serialization applies to them. morphir-ts is in the elm chain because it invokes elm indirectly via node-elm-compiler in cli/morphir-elm.js (visible as "Compiled in DEV mode" in its output). Verified locally on Windows with a cold elm-stuff: full build completes successfully. * feat(mise): declare sources/outputs for incremental rebuilds Add `//MISE sources=[...]` / `outputs=[...]` to every build subtask so mise can skip a task whose inputs haven't changed. The orchestration in build.ts already invokes each subtask via `mise run --skip-deps`, so the freshness check kicks in on every step independently. Cold rebuild from a clean tree still does the full work serially. Warm rebuild with no source changes finishes in seconds (mise reports "sources up-to-date, skipping" for each elm task). Touching a single .elm file rebuilds only the affected tasks — for example, touching cli/src/Morphir/Web/TryMorphir.elm reruns cli, dev-server, try-morphir, components, and morphir-ts but leaves check-elm-docs, cli2, and treeview skipped. Notes: - Patterns are deliberately broad (`src/**/*.elm`, `cli/src/**/*.elm`) rather than module-precise. elm tracks transitive imports itself, so conservative globs trade a few extra rebuilds for safety. - build:components has no sources/outputs because its output overlaps its input (concat insight.js + morphir-insight-element.js → insight.js), which would make mtime-based freshness ambiguous. It's a fast concat and always re-runs. - Removed the Promise.all that ran build:treeview alongside the elm chain — the speedup was marginal and the fully serial form is easier to reason about now that each subtask gets independent freshness caching.
Summary
setup:npmmise task that runsnpm ciat repo rootsetup:elm-toolingto depend onsetup:npm(elm-tooling needsnode_modules/.bin/elm)setup:npmin thesetupaggregate tasknpm cistep from CI workflow (mise run defaultnow handles it)npm ciinstructions withmise run defaultBefore
New contributors had to manually run
npm cibeforemise run defaultwould work on a fresh clone.After
mise run default # single command — installs deps, builds, testsTest Plan
mise tasks | grep setup:npmshows the taskmise tasks deps setupshowssetup:npmin dependency graphmise run setup:npmruns npm ci successfully