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

The vite.build.target setting does not take effect in dev mode. #12655

Open
1 task done
koyopro opened this issue Dec 5, 2024 · 9 comments · May be fixed by #12676
Open
1 task done

The vite.build.target setting does not take effect in dev mode. #12655

koyopro opened this issue Dec 5, 2024 · 9 comments · May be fixed by #12676
Labels
needs triage Issue needs to be triaged

Comments

@koyopro
Copy link
Contributor

koyopro commented Dec 5, 2024

Astro Info

Astro                    v5.0.3
Node                     v22.2.0
System                   macOS (arm64)
Package Manager          npm
Output                   static
Adapter                  none
Integrations             none

If this issue only occurs in one browser, which browser is a problem?

No response

Describe the Bug

The vite.build.target setting does not take effect in dev mode.

I want to use the decorator feature introduced in TypeScript 5.0.
https://devblogs.microsoft.com/typescript/announcing-typescript-5-0/#decorators
This new decorator feature is supported in esbuild 0.21.0 and above.
https://github.com/evanw/esbuild/releases/tag/v0.21.0
According to the esbuild documentation, by specifying a target value lower than "esnext" (such as "es2022"), decorators will be transformed and can be executed in Node.js.
https://esbuild.github.io/content-types/#javascript

In an Astro project, esbuild is executed via Vite, but by default, the target seems to be set to "esnext".
So, I added the following configuration to astro.config.mjs:

export default defineConfig({
  vite: {
    build: { target: 'es2018' },
  }
});

This configuration works as expected when running npm run build, and the decorators are transformed.
However, when running npm run dev, the decorators are not transformed, resulting in an "Invalid or unexpected token" error.
(Incidentally, if the target is not specified, the decorators are not transformed even during npm run build, resulting in the same error.)

image

What's the expected result?

I expect the vite.build.target setting to take effect during npm run dev as well, so that the decorators are transformed and the above error does not occur.

Link to Minimal Reproducible Example

https://stackblitz.com/github/koyopro/astro-debug/tree/build_target?file=src%2Fpages%2Findex.astro

Participation

  • I am willing to submit a pull request for this issue.
@github-actions github-actions bot added the needs triage Issue needs to be triaged label Dec 5, 2024
@koyopro
Copy link
Contributor Author

koyopro commented Dec 5, 2024

I thought the issue could be resolved by specifying the target when running esbuild, so I investigated where esbuild is executed during npm run dev.

As a result, I found that the output of transformWithEsbuild is used at the following location:
Here, 'target: "esnext"' is specified.

esbuildResult = await transformWithEsbuild(transformResult.code, compileProps.filename, {
loader: 'ts',
target: 'esnext',

As an experiment, I modified this part to 'target: "es2018"', and found that the decorators were transpiled, and the error no longer occurred during npm run dev.

@koyopro
Copy link
Contributor Author

koyopro commented Dec 5, 2024

I would like to create a Pull Request to modify the above location (packages/astro/src/vite-plugin-astro/compile.ts) so that the value of vite.build.target is reflected.
(If there is a preferred method for this fix, please let me know.)

@bluwy
Copy link
Member

bluwy commented Dec 6, 2024

You need to use vite.esbuild.target instead: vitejs/vite#17308 (comment). vite.build.target as its name suggests is for build only.

@koyopro
Copy link
Contributor Author

koyopro commented Dec 6, 2024

@bluwy Thank you for your response!

I have also added the vite.esbuild.target setting as shown below.
However, the same error still occurs.
Is there anything else I should check?

// astro.config.mjs
export default defineConfig({
  vite: {
    build: { target: 'es2018' },
    esbuild: { target: 'es2018' }, // added
  }
});

I have also added this to the example.
https://stackblitz.com/github/koyopro/astro-debug/tree/build_target?file=astro.config.mjs

@koyopro koyopro linked a pull request Dec 7, 2024 that will close this issue
@koyopro
Copy link
Contributor Author

koyopro commented Dec 10, 2024

@bluwy As you pointed out, it seems more appropriate to apply vite.esbuild.target rather than vite.build.target, so I have submitted a Pull Request for that. Could you please review it?
fix: Reflect the configuration for esbuild by koyopro · Pull Request #12676 · withastro/astro

@sebthom
Copy link

sebthom commented Dec 27, 2024

Is there a workaround for this? I upgraded from Astro 4 to 5.1 and I am hitting a similar/the same issue Unexpected token ';' in "node/module-runner.js:1049:11". Unfortunately the stacktrace and line number reported do not match the actual source location, so I have no idea where the syntax error actually happens.

image

I am on Windows 10 with Node 22.12.0 + PNPM 9.15.1

@koyopro
Copy link
Contributor Author

koyopro commented Dec 28, 2024

@sebthom That error might indeed be the same issue.

I don't have a simple workaround.
One idea might be to use patch-package - npm to fix the relevant file.

node_modules/astro/dist/vite-plugin-astro/compile.js
image

@sebthom
Copy link

sebthom commented Dec 29, 2024

@koyopro This didn't help in my case but I found out that the issue disappears in Astro 5 when I remove the usage of https://github.com/Dovias/astro-runtime-config in my project.

@koyopro
Copy link
Contributor Author

koyopro commented Dec 29, 2024

@sebthom Now that you mention it, the fact that it doesn't reproduce on Astro 4 but does on 5.1 makes me think this might be a separate issue.
I believe my issue occurs even on Astro 4.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs triage Issue needs to be triaged
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants