fix: explicitly set dev mode for data store#12947
Conversation
🦋 Changeset detectedLatest commit: 54dff26 The changes in this PR will be included in the next version bump. Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
!preview data-store-location |
|
Snapshots have been released for the following packages:
Publish LogBuild Log |
CodSpeed Performance ReportMerging #12947 will not alter performanceComparing Summary
|
|
I tested the experimental release for this PR against Starlight’s end-to-end tests (which fail with Astro 5.1.x currently) and it seems to resolve things for us: withastro/starlight#2776 |
| const dataStoreFile = getDataStoreFile(settings, isDev); | ||
| store = await MutableDataStore.fromFile(dataStoreFile); |
There was a problem hiding this comment.
existSync is now marked unused
|
|
||
| describe('build --mode testing --devOutput', () => { | ||
| before(async () => { | ||
| await deleteDataStoreFiles(); |
There was a problem hiding this comment.
Any particular reason why we use this in before and not in after?
There was a problem hiding this comment.
We're checking the creation of the files, so I wanted to be explicit in deleting any leftover ones before running the build.
0e66162 to
8e56262
Compare
Changes
The content layer data store is created in a different location according to whether it is running in dev or build, so that it is either cachable or watchable by the fs watcher. These are mutually exclusive for Reasons.
This needs to be the same locaiton for both writing (during sync) and reading (during runtime). Unfortunately knowing which of these we're running is not as simple as it could be, and there have been some bugs that have emerged due to conflicts.
We'd mostly fixed these cases in #12640, but it missed the case where dev was run programatically with NODE_ENV set to something other than development (mostly in a test environment).
Rather than playing whackamole for all of these scenarios, this PR changes the approach so that it never uses NODE_ENV, and always explicitly sets it. Either this is done via the command used (build and sync use production, dev uses development) or at runtime uses Vite's env.command (build uses production, serve uses development). This involved some refactoring around how files are handled by data stores (which was overdue, because it was needlessly complex as it was created when there were different requirements)
Fixes #12652
Testing
Added some tests to the astro mode suite, which helpfully messes around with these options.
Docs