fix(event-display): server staleness - #976
Merged
Merged
Conversation
…tart Both READMEs claimed that changes to either linked package rebuild and hot reload the app. That is only true of phoenix-ui-components, which is path mapped straight to its source. phoenix-event-display resolves through the node_modules symlink to its main, dist/index, so the app consumes built output — and Angular's watcher does not watch inside node_modules. `yarn start` does run the library in watch mode, which is presumably why the claim looked true, but the two start concurrently and ng serve usually finishes bundling before the first library build writes dist. The result is a change that is present in dist yet absent from the running app, with nothing in the browser to explain it. Documents the rebuild-then-restart step and how to spot the case by comparing the dist and dev server timestamps. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Rebuilding the library and restarting ng serve was still not enough to pick up a change. Because phoenix-event-display resolves through node_modules, the Vite-based dev server treated it as a third-party dependency and pre-bundled it into .angular/cache/**/vite/deps/. That cache is keyed on package metadata rather than file contents, so a dist rebuild never invalidated it and a restart happily reused it: the served copy here was two days old and had none of the last three commits in it. angular.json now excludes the package from pre-bundling, so it is bundled from source on every serve. Verified: @angular/cdk and the rest are still pre-bundled, while vite/deps/phoenix-event-display.js is no longer produced. The README section added in 772e416b described the concurrency race between the library watch build and ng serve, which is real but was not the whole story — it stopped short of the cache, which is the part that survives a restart and makes the symptom so confusing. Corrected in both READMEs. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`yarn start` ran the library watch build and ng serve concurrently through lerna, and ng serve consistently won: it finished bundling several seconds before the first library build wrote dist, so a fresh start served whatever dist was left from the previous session. This cost three separate debugging rounds today, each one looking like the change had simply not worked. Building the library once up front removes the race — by the time lerna starts ng serve, dist is current. Editing the library still needs a restart, because Angular's watcher does not watch inside node_modules. That part is unavoidable here and stays documented. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
EdwardMoyse
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is an attempt to fix the ongoing problem that yarn start has not been picking up all the backend changes.