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

agilgur5 commented 2 years ago

This reverts commit e145d0baebbbef1eec691b99d1ce0dce1e49f38c / 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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

ezolenko commented 2 years ago

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

agilgur5 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

ezolenko / rollup-plugin-typescript2