Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: define no longer follows the esbuild rules #12156

Closed
wants to merge 1 commit into from

Conversation

fi3ework
Copy link
Member

Description

In Vite 2.x, config.define is passed to esbuild to perform the replacement.

for (const key in config.define) {
const value = config.define[key]
define[key] = typeof value === 'string' ? value : JSON.stringify(value)
}
const start = performance.now()
const result = await build({
absWorkingDir: process.cwd(),
entryPoints: Object.keys(flatIdDeps),
bundle: true,
format: 'esm',
target: config.build.target || undefined,
external: config.optimizeDeps?.exclude,
logLevel: 'error',
splitting: true,
sourcemap: true,
outdir: cacheDir,
ignoreAnnotations: true,
metafile: true,
define,

For now, config.define is no longer passed to esbuild when performing optimization. The line this PR deleted is introduced in #5570. The reproduction that time works on Vite4 now.

Made a new demo to confirm https://stackblitz.com/edit/vite-nitjua?file=package-lock.json,vite.config.js&file=main.js

Additional context

We should bring this back after #11151 landed.


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.

@bluwy
Copy link
Member

bluwy commented Feb 25, 2023

Looks like the limitation was indirectly removed in #8606. But I think if we're planning to go with #11151 one day (which I could revisit again), maybe it's good to pre-emptively mention this limitation so one that PR lands, it doesn't cause too much breaking changes to users.

@fi3ework
Copy link
Member Author

Looks like the limitation was indirectly removed in #8606. But I think if we're planning to go with #11151 one day (which I could revisit again), maybe it's good to pre-emptively mention this limitation so one that PR lands, it doesn't cause too much breaking changes to users.

Make sense. 😜

@fi3ework fi3ework closed this Feb 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants