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.
Changes
Users can know pass custom
--mode
other thanproduction
anddevelopment
, likestaging
or anything else etc.Within Astro, how do we actually tell in we're in dev or prod state now?
For
astro dev
, it'll always be in the dev state. It's not possible to be in a prod state as it may break existing code, like HMR and stuff (which is also a restriction in Vite)For
astro build
, it'll be prod state by default, unless the user passes--dev
which Astro will then switch to a dev state.In other parts of the codebase, there's also the concept of
runtimeMode
which contains this state as either"development"
or"production"
values only.Future coding style
If we want to check the prod or dev state, we should no longer rely on
mode
as that's no longer relevant. We can check via these states instead:viteResolvedConfig.isProduction
runtimeMode
process.env.NODE_ENV === 'production'
import.meta.env.PROD
andimport.meta.env.DEV
Testing
Added a new test to verify that it works.
Docs
TBA. The
--dev
flag will require docs.