Local demo serves stale editor bundles after source changes

Open
  • Is something wrong?
#24 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@jacilynh is already working on this.

Since Nov 10, 2026.

  • #25 by @jacilynh — open

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Stale
Tech stack
node.js, typescript
Domain
build-system, developer-experience

Research direction

Start in packages/bim-editor/demo/build.ts by reading ensureEditorDemoBuilt, its pending map, and freshBuild to understand how freshness checks and concurrent requests work. Add regression coverage for unchanged cache reuse, rebuilding after a source change, concurrent requests, and retrying failed builds; the issue proposes a focused signed-off PR, and an open linked PR is already in progress.

Written by the indexing model from the issue text.

Description

What happened

While testing an editor fix with the local demo, changing source code and reloading the browser continued to show the old behavior. Restarting the dev server rebuilt the editor and picked up the change.

ensureEditorDemoBuilt in packages/bim-editor/demo/build.ts retains its resolved promise in the pending map. Later page/asset requests return that same promise before reaching freshBuild, so the existing source-mtime check is never run again in that process. The map entry is currently removed only on failure.

Expected behavior

Concurrent requests should share one in-progress freshness check/build. Once it settles, later requests should check the disk cache again: reuse unchanged output and rebuild when a tracked source changed. A failed rebuild should remain retryable.

This does not require a file watcher or hot module replacement; a browser reload should be enough.

Steps to reproduce

  1. Run npm run demo and open the editor, allowing its first build to finish.
  2. Change visible editor text in a source file included in the bundle.
  3. Reload the page without restarting the server.
  4. Observe that the old text remains. Restart the server and reload; the new text appears.

Area / environment

Local editor demo build cache, not trade-specific. Observed on macOS with Node 22.23.1 and Chrome; the retained-promise path is platform independent.

The same map lifecycle remains on current upstream main. I searched upstream for a matching rebuild issue and did not find one.

Proposed scope

Release completed entries while preserving in-flight request sharing. Add regression coverage for unchanged-cache reuse, rebuilding after a source change, concurrent requests, and recovery from failed builds. I plan to follow up with a focused signed-off PR.

No client models, credentials, or real project data are needed to reproduce this.

Dominant language
TypeScript
Stars
85
Forks
10
Avg merge
1h 28m
Merged PRs (30d)
20

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from permitzip/mutinybim

All issues in permitzip/mutinybim

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.