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

fix(esbuild): enable experimentalDecorators by default #13805

Merged
merged 2 commits into from Jul 13, 2023

Conversation

bluwy
Copy link
Member

@bluwy bluwy commented Jul 12, 2023

Description

(potential) fix #13736. however there were some reports that this doesn't work, so probably worth holding off this PR for now.

follow up on #13525, not setting experimentalDecorators by default seems to be causing issues at the moment, it might be better to turn this on by default for now and disable it in Vite 5 again.

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.

@stackblitz
Copy link

stackblitz bot commented Jul 12, 2023

Review PR in StackBlitz Codeflow Run & review this pull request in StackBlitz Codeflow.

patak-dev
patak-dev previously approved these changes Jul 12, 2023
@bluwy
Copy link
Member Author

bluwy commented Jul 13, 2023

Pushed a commit to enable experimentalDecorators during scan too. It turns out the scanner doesn't really use the project's tsconfig.json at the moment because we're passing stdin. If I pass an explicit tsconfig: 'tsconfig.json' config to esbuild, only then it detects it.

I didn't go with that fix for now as it might affect scanning perf, or cause another unexpected behaviour. We should be able to circle back on this in Vite 5 as an error will appear when we remove the experimentalDecorators default.

@patak-dev patak-dev added p3-minor-bug An edge case that only affects very specific usage (priority) regression The issue only appears after a new release labels Jul 13, 2023
@patak-dev
Copy link
Member

/ecosystem-ci run

@vite-ecosystem-ci
Copy link

vite-ecosystem-ci bot commented Jul 13, 2023

📝 Ran ecosystem CI: Open

suite result
analogjs ✅ success
astro ✅ success
histoire ❌ failure
iles ❌ failure
ladle ✅ success
laravel ✅ success
marko ✅ success
nuxt ✅ success
nx ✅ success
previewjs ✅ success
qwik ✅ success
rakkas ✅ success
sveltekit ✅ success
unocss ✅ success
vite-plugin-pwa ✅ success
vite-plugin-ssr ✅ success
vite-plugin-react ✅ success
vite-plugin-react-pages ✅ success
vite-plugin-react-swc ✅ success
vite-plugin-svelte ✅ success
vite-plugin-vue ✅ success
vite-setup-catalogue ✅ success
vitepress ✅ success
vitest ✅ success

Comment on lines +225 to +234
tsconfigRaw:
typeof tsconfigRaw === 'string'
? tsconfigRaw
: {
...tsconfigRaw,
compilerOptions: {
experimentalDecorators: true,
...tsconfigRaw?.compilerOptions,
},
},
Copy link
Member

@patak-dev patak-dev Jul 13, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we should use (and only add the prop if tsconfig isn't defined):

Suggested change
tsconfigRaw:
typeof tsconfigRaw === 'string'
? tsconfigRaw
: {
...tsconfigRaw,
compilerOptions: {
experimentalDecorators: true,
...tsconfigRaw?.compilerOptions,
},
},
tsconfigRaw:
tsconfigRaw ?? {
compilerOptions: {
experimentalDecorators: true,
},
},
},

so it works consistently for the three cases, experimentalDecorators is only set if the user doesn't manually modify the config.

  • tsconfigRaw is an object
  • tsconfigRaw is a string
  • tsconfig passed as a path

Right now, only the object form is respected. Or the other way around, the file or string could be first converted to an object.

I'm fine moving forward with the current patch though if we consider it as a temporal solution to help the majority of users. We could add a comment here in that case

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't that not apply the experimentalDecorators: true default if the user pass something like { compilerOptions: { useDefineForClassFields: true } }. Currently in transformWithEsbuild having that config would fallback with experimentalDecorators: true too. I think for string form it's fine to respect the user input completely like transformWithEsbuild does for now.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess it would be a bit complicated to do it correct, since we will have to load/parse the tsconfig.
I think it's ok with this implementation if we add a small section to the changelog.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh you're right that tsconfigRaw would've overwrite tsconfig if only tsconfig is set (iirc) 🤔 I think we can not set tsconfigRaw if tsconfig is specified?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it won't apply it in that case. I find it inconsistent to only do it for the object form, so I was trying to see what would be correct here. But I was thinking along the lines of what @sapphi-red said. Let's merge this one as is for now then.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, it seems an error happens. esbuild repl
So we need to skip adding tsconfigRaw if tsconfig exists.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah ok I can fix that in a followup PR now.

Comment on lines +225 to +234
tsconfigRaw:
typeof tsconfigRaw === 'string'
? tsconfigRaw
: {
...tsconfigRaw,
compilerOptions: {
experimentalDecorators: true,
...tsconfigRaw?.compilerOptions,
},
},
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess it would be a bit complicated to do it correct, since we will have to load/parse the tsconfig.
I think it's ok with this implementation if we add a small section to the changelog.

@patak-dev patak-dev merged commit e8880f0 into main Jul 13, 2023
13 checks passed
@patak-dev patak-dev deleted the enable-experimental-decorators branch July 13, 2023 12:52
@hybridherbst
Copy link

If one wants to use the non-experimental decorators from TypeScript 5 (which are different), how would that work now that the experimental ones are enabled by default?

@bluwy
Copy link
Member Author

bluwy commented Jul 14, 2023

IIUC you can still use the non-experimental decorators, just that experimental decorators extends some non-standard syntax. That was also why I didn't caught the second bug in the issue as I was only testing the standard decorators.

Note though that esbuild only implements pass-through mode for them in esbuild.target: 'esnext'. It doesn't down-level the syntax yet. A future release would improve this.

@spencer17x
Copy link
Contributor

It still doesn't seem to work. The property decorator is invalid

@patak-dev
Copy link
Member

@spencer17x would you create a new issue with a minimal reproduction against vite@4.4.4?

@spencer17x
Copy link
Contributor

#13874 @spencer17x

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
p3-minor-bug An edge case that only affects very specific usage (priority) regression The issue only appears after a new release
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

Using vite 4.4.0 or 4.4.1 breaks Typescript decorator support in some projects
5 participants