Support custom mode

[bluwy]

Changes

Users can know pass custom --mode other than production and development, like staging 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 --devOutput 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:

1. viteResolvedConfig.isProduction
2. runtimeMode
3. process.env.NODE_ENV === 'production'
4. import.meta.env.PROD and import.meta.env.DEV

Testing

Added a new test to verify that it works.

Docs

withastro/docs#9641

[changeset-bot]

🦋 Changeset detected

Latest commit: 7c9b09e

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

[github-actions]

This PR is blocked because it contains a minor changeset. A reviewer will merge this at the next release if approved.

[ematipico]

I really like the fact that we internally create a distinction between "command" and "mode"

[sarah11918]

Looks great @bluwy ! I'm not sure if it was intentional, but devOutput was kind of glossed over so I added a sentence to introduce it as a new thing. Some suggestions for your consideration!

[bluwy]

Looks great! I didn't document --devOutput a lot as it's not a very common thing needed for most people. But happy to emphasize that a bit too.

[sarah11918]

🥳