Could the project please publish a changelog?

[ThisIsMissEm]

Hi! Would it be possible to get a CHANGELOG.md file publish or releases on github setup?

Currently when you release a new version, the only thing I can look at is the commits for changes, which are often far too involved for users of your package to understand. That and the semver version, but that relies on you strictly adhering to semver, which generally isn't the case in the npm ecosystem from what I've seen.

This would make upgrading versions much easier for downstream developers to approach; right now I just have to hope the update doesn't break anything.

[agilgur5]

Release Notes

releases on github setup?

Have you seen the past 3 releases on GitHub?

I wrote up those 3 as I was added as a maintainer a few months ago after being a long-time contributor. I've made significant improvements to the codebase, issues, labels, templates, testing, etc, including improving the release notes (as linked above) by adding highlights, descriptions, links, summaries, etc. (The past few releases also include significantly more changes than before due to my involvement, so spoiler tags etc have also been added).

These should be much better than the previous release notes as such. I don't have publishing permissions though, so I write/edit them up async after ezolenko publishes a release currently. Otherwise, I can relate to your concern about the lack of changelogs in the past, as when I was just a user/contributor, I myself had previously clamored about it as well and read through diffs to see the changes. Release notes take time to write well, so understandably, ezolenko in his solo capacity didn't have the time to do (or learn to do) everything well.

If you'd still like to see more improvements to the release notes than those already done, please let me know what kind of specific stylistic changes you think would be helpful in particular, always open to improving the craft! (In my experience as a maintainer of multiple libraries, release notes are "more of an art form than a science" 😅 and can vary widely between types of libraries as well each individual release depending on the changes therein. For instance, releases I had written for TSDX (such as this one) were different than any other library I'd maintained due to the extreme user-facing impact of any change in that library. So specific feedback for this library in particular could be helpful!)

Dependabot

I noticed from your contribution history (was looking to see if there was a downstream discussion somewhere with more details/feedback) that some of the repos you maintain use Dependabot, and in some PRs, Dependabot did include the detailed notes from GitHub Releases. Though it looks like it missed them in the last version bump. That might be because, per 0.33.0's release notes, of a tagging mistake ezolenko accidentally made this release. That's the only time that's happened and I don't think either of us knew it would impact Dependabot PRs as such, so apologies on the inconvenience.

Rest assured though, that the GitHub Releases page has always had some form of release notes, so can always reference that if Dependabot etc don't manage to find it (though an edited version might be a bit delayed, per my note above).

CHANGELOG.md

Would it be possible to get a CHANGELOG.md file

I actually just realized that there is no CHANGELOG.md in this repo 😮

I normally have a simple one in my libraries that just points to the release notes on GH Releases for clarity / less confusion, but I guess I never noticed or added one since becoming a maintainer here.

Thanks for pointing that out, I'll add a similar one shortly! 🙂 EDIT: See #419

Breakage Testing

right now I just have to hope the update doesn't break anything.

If you want to be really certain, testing your output bundles can be a helpful check. For example:

• ezolenko does a kind of "snapshot" eye-test with the dist/ diffs in this repo.
• I've seen others write automated snapshot tests of bundles with Jest (such as microbundle's snapshots).
• In integration/e2e tests here (and in TSDX), I compare the output with expected strings etc. (Personally, I prefer that to snapshot testing, since relying on eye-testing in code review can be more error-prone.)

SemVer

That and the semver version, but that relies on you strictly adhering to semver, which generally isn't the case in the npm ecosystem from what I've seen.

Just for reference, historically, ezolenko is very conservative with versioning, preferring releasing a minor over patch change (and since rpt2 is still in 0.x, minors can be breaking) when there's a possibility for breakage. Can see an example of that in our discussion about the numbering for the latest release.

Personally, I'd also disagree with the characterization that generally the NPM ecosystem doesn't adhere to SemVer, as I think it does so better than any other package manager ecosystem I've worked with (IMO; Python and Go, for instance, didn't even have advanced package managers until recently (poetry and Go modules, respectively)). Alternative versioning schemes, like ComVer, that try to improve on the subjectivity of SemVer, were also largely born out of the JS/TS ecosystem. But that's neither here nor there. (I just truly appreciate some of the early advances to package management that NPM brought!)

TypeScript is also a bit of sub-ecosystem and this seems to be not that well-known in the TS ecosystem, so wanted to note here just in case (either for you or other readers of this issue): TS itself does not strictly follow SemVer, as that can be very difficult with a type-checker (e.g. a feature of that adds a type-error will break existing users), among other reasons. So downstream packages may be impacted by that too.