fix(define): inconsistent env values in build mode

[sun0day]

Description

1. import.meta.env.KEY value maybe inconsistent with KEY value in import.meta.env object in build mode.

// `vite.config.js`:

{
  define: {  'import.meta.env.VITE_BOOL': true }
}

# .env
VITE_BOOL=whatever

After building, import.meta.env.VITE_BOOL replaced with true while import.meta.env replaced with {VITE_BOOL: 'whatever'}

2. import.meta.env.SSR added by vite was not exposed to import.meta.env in build mode.

Additional context

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Before submitting the PR, please make sure you do the following

• Read the Contributing Guidelines.
• Read the Pull Request Guidelines and follow the PR Title Convention.
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Ideally, include relevant tests that fail without this PR but pass with it.

[patak-dev]

Should 1 be supported? Isn't the user asking Vite to do two incompatible things? Shouldn't we enforce the user to have string values for import.meta.env.xxx?

{
  define: {  'import.meta.env.VITE_BOOL': JSON.stringify('true') }
}

[sun0day]

Should 1 be supported? Isn't the user asking Vite to do two incompatible things? Shouldn't we enforce the user to have string values for import.meta.env.xxx?

{
  define: {  'import.meta.env.VITE_BOOL': JSON.stringify('true') }
}

Sorry I didn't describe this case clearly. First of all, vite didn't restrict users from defining the non-string import.meta.env.xxx values according to the UserConfig.define types and the playground/env test cases.

And when I set {define: { 'import.meta.env.VITE_BOOL': X}}, what I expected is that import.meta.env.VITE_BOOL will be replaced with X and import.meta.env will be replaced with {"VITE_BOOL": X} no matter what VITE_BOOL value is in .env files after building.

[patak-dev]

Some more context about this PR here. We discussed with @sun0day and @bluwy, that it is a good idea to move forward with this PR as it is clear that define always win against .env. But later on, it may be helpful to issue a warning if there is a non-string value in define that is also defined in .env.