revert: back to using vue.d.ts instead of .d.ts for Vue declarations

[agilgur5]

This reverts commit e145d0b / PR #336
NOTE: this may be considered breaking, so we may want to release this in a breaking release as such. I've left this PR as draft as such. That being said, this could also be considered as just a bugfix as the original PR was made in error and caused a bug.

Summary

Revert back to using .vue.d.ts for Vue declarations

Details

• Per follow-up discussion on the original issue and to-be-reverted PR, it seems that the request to use .d.ts instead of .vue.d.ts was made in error
  • .d.ts seems to only be necessary if Vue users were importing .vue SFCs without extensions ("extensionless")
    • i.e. import MyComponent from "./MyComponent" instead of import MyComponent from "./MyComponent.vue"
  • and "extensionless" imports are no longer supported by the Vue team (but used to be)
  • requiring extensionless imports also breaks imports when extensions are used
  • so these are not necessarily compatible with each other, but the Vue team support strongly suggests that .vue.d.ts would be the proper way forward

Credits

Thanks to @andrew0 for finding this problem and providing evidence 🙂

[ezolenko]

Yeah, we should support official way of importing, so looks good.

Do we want to release this sooner than later? Any other PRs you want to include (or exclude)?

[agilgur5]

Do we want to release this sooner than later? Any other PRs you want to include (or exclude)?

So depends if we're considering this as a breaking change or not.
If it's a patch, then I think this PR can go out with all the other already merged changes into 0.32.2.
If we're considering this as breaking, then it probably makes sense to release along with #406 . So then I'd think to release 0.32.2 with the already merged changes and then this PR and #406 as part of 0.33.0.

Exclude-wise, I was just thinking of leaving #406 until either 0.32.3 or 0.33.0 (pending patch/breaking classification), and releasing 0.32.2 on its own without #406. Just because #406 is a big change and there's enough changes already merged in for a sizeable release.

The rest of my PRs in the queue should not affect the release one way or another as they're only testing changes, clean-up, or refactors; i.e. no functional changes to the plugin itself.

[ezolenko]

I think we should do 0.33 then without #406, and then 0.34 with that when it is ready

[ezolenko]

@agilgur5 0.33.0 is out, maybe check if release notes make sense and edit them if you want anything changed

[agilgur5]

I think we should do 0.33 then without #406, and then 0.34 with that when it is ready

Ok, up to you 👍 Your releases consistently err on the side of breaking (vs. patch), so that's maybe more expected for rpt2 users too, in that sense.

@agilgur5 0.33.0 is out, maybe check if release notes make sense and edit them if you want anything changed

Thanks for (mostly) copying my release notes style!
I made a few adjustments, for reference:

• put "Optimizations", "Docs", and "GitHub" sections outside of the "Other"/"Internal" section as they are user-facing and so may be good to highlight
• put this PR, which begins with revert: into the "Bugfixes" section
• put the dx: PRs into the "Docs" section (that's kind of the closest thing to it)
• highlighted a few of the "Internal" changes before the spoiler too -- think users would be happy to see all the testing additions at least!
• hid a few "Bugfixes" etc under a spoiler where they were not user-facing or very minor in nature
• added explanations to several of the "Bugfixes" where the PR title would not necessarily be understood by users

I also saw that the dist/ build was missing in the release initially, then saw that you re-tagged it. Looks like NPM has the build already, so seems all good minus some tag confusion 👍

[ezolenko]

I basically took autogenerated release notes with your commit messages and rearranged them to hide internal stuff, so those are literally your release notes. :)

Yeah, forgot to push local branch with build commit before tagging on github :/

[agilgur5]

I basically took autogenerated release notes with your commit messages and rearranged them to hide internal stuff, so those are literally your release notes. :)

Yep that's the basic gist of the structure I use 👍 plus a few manual things where explanations could be helpful

Yeah, forgot to push local branch with build commit before tagging on github :/

Yea I've done that multiple times before too 😅

If you're interested, we can also automate the release process with GH Actions too