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

Using export & then using decorator before the word "default" breaks SFC compilation. #13060

Closed
andrewbrennanfr opened this issue Jul 28, 2023 · 4 comments

Comments

@andrewbrennanfr
Copy link

Version

2.7.14

Reproduction link

https://stackblitz.com/edit/vitejs-vite-bctp3t?file=src%2FApp.vue

Steps to reproduce

  • Export a const from a SFC.

  • Use a vue-property-decorator with @Component & export your class component as default.

  • Include the word "default" in a comment (for example).

  • Your component is not built correctly - in my reproduction example, the props are not initialized as an object. (you can see there is also no console warning related to someString).

  • Remove the word "default" from the comment & refresh the page - props will initialize correctly & you also have the expected console warning.


Looks very similar to several issues (such as this one & this one)

Apparently this has been fixed here.

However it fails to work for me when @babel/parser is upgraded beyond 7.19.6
🟢 Working use case with 7.19.6
🛑 Non-working use case with 7.20.0


After some debugging it seems that the method hasDefaultExport in vuejs/vue is the one that's broken for this case & the one in vuejs/core is working.
https://github.com/vuejs/vue/blob/main/packages/compiler-sfc/src/rewriteDefault.ts#L91-L93

This regex change here would cause some unit tests (for my use case) start to fail. And for me this regex is maybe too loose.

Here 👉 there's no default export, yet this regex is a match https://regex101.com/r/LmYL8l/1

What is expected?

I expect my component to be built correctly & to not have a comment impacting the behavior of my component.

What is actually happening?

When inspecting the compiled code - it looks to me that the @Component decorator here is just completely stripped in the outputted code.


🙈 I've probably mistakenly opened an issue on vue/core here


Workaround for me, is to override @babel/parser for @vue/sfc-compiler to be 7.19.6 and the problem disappears.

Removing the exported const/type/interface/etc from the SFC works around the issue.

Moving the exported const/interface/type/etc below the class component also works around the issue.

This issue is not isolated to only comments, but rather the presence of default.
Meaning, code such as @Prop({ type: String, required: false, default: '' }) is also breaking - as the word default here has the same impact.

💡 I've attempted a sort of "backport" of the changes from vue/core & added a test for my use case. It looks to work.
https://github.com/andrewbrennanfr/vue/commits/fix/rewriteDefault-decorator-parsing

@andrewbrennanfr
Copy link
Author

Perhaps this could be a cleaner "fix" - making the regex's a bit more explicit?
andrewbrennanfr@e6e26fb

@gbalduzzi
Copy link

gbalduzzi commented Aug 4, 2023

I'm seeing the same problem in vite. This was a very nasty bug to debug and discover.

Workaround for me, is to override @babel/parser for @vue/sfc-compiler to be 7.19.6 and the problem disappears.

Not sure how to accomplish the same result this with vite and @vitejs/plugin-vue2

I forced the babel parser to 7.19.6 with yarn add @babel/[email protected] but the issue persists

@andrewbrennanfr
Copy link
Author

@gbalduzzi Not sure it's particularly to do with Vite. We use Vite also & still managed to work around it.
I don't know your specific setup, but not sure running yarn add @babel/[email protected] would necessarily fix it.
Adding something like:

"overrides": {
        "@vue/compiler-sfc": {
            "@babel/parser": "7.19.6"
        }
}

To our package.json definitely overrides @babel/parser & "fixes" the issue.

Bare in mind, our intention is that this is temporary. Upgrading to vue3 should resolve the issue properly

@gbalduzzi
Copy link

@andrewbrennanfr thank you, I can confirm this works.

Yes, this is a temporary solution for us too while we migrate to vue3

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

No branches or pull requests

2 participants