Closed agilgur5 closed 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)?
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.
I think we should do 0.33 then without #406, and then 0.34 with that when it is ready
@agilgur5 0.33.0 is out, maybe check if release notes make sense and edit them if you want anything changed
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:
revert:
into the "Bugfixes" sectiondx:
PRs into the "Docs" section (that's kind of the closest thing to it)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 👍
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 :/
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
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 declarationsDetails
.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")import MyComponent from "./MyComponent"
instead ofimport MyComponent from "./MyComponent.vue"
.vue.d.ts
would be the proper way forwardCredits
Thanks to @andrew0 for finding this problem and providing evidence 🙂