How to scope changelog to directory

[markcellus]

Hello, love this package! Forgive me if this is already been covered (and I somehow missed it) 🤗 But is it possible to only generate a changelog for the files in a particular directory other than the root? We have a repo that contains multiple directories that each need their own release notes generated.

[cookpete]

Unfortunately the script doesn't pull any data about specific files changed in each commit. This would be an awesome (and useful) feature, but would require a pretty huge change to implement (and would take much longer to generate changelogs).

[ljharb]

Since git log can filter commit messages by path, I’m not sure why this would be particularly difficult or slow.

[cookpete]

Good point @ljharb. You could get there with --append-git-log, but your versions won't show up unless each version commit changes something inside your target directory?

[markcellus]

Yeah wouldn't that be synonymous to trying to create a log with no diff? In other words, wouldnt this be the case now? Even without this change?

[cookpete]

I suppose a solution could be to fetch both the original list of commits (to gather the version commits) and the commits filtered by path, then filter out any commit from the original list that isn't a version commit or part of the filtered list. If there is a big demand for this I can take a look, but I think my original comment still holds true – it's a fairly unpleasant change to the simplicity of the current logic.

[markcellus]

Yup, adding a new feature will always make a codebase a little more complex. How are you evaluating whether there is a "big demand"? Most people use this package indirectly as a transitive dependency and never really need to come directly to this repo so I'm unsure of how they'd find this issue to vote on it. In fact, I had to do quite a bit of sleuthing to find this repo myself haha.

At any rate, if this feature is added, it would be the first library that makes it easy to create release notes for monorepos (repos that ship multiple packages). AFAIK, there is no other releaes management library that does it--not even lerna, release-it, or semantic-release, which are some of the most popular release libs out there.

[markcellus]

Here are a few issues that I found that show there is some interest in a feature to establish changelogs per directory/package in a repo:

release-it/release-it#516
pmowrer/semantic-release-monorepo#72
lerna/lerna#1562
conventional-changelog/conventional-changelog#167

Let me know your thoughts.

[cookpete]

Yup, adding a new feature will always make a codebase a little more complex.

Not sure if this was sarcastic or not.. I'm aware that features add complexity. My issue is whether the amount of added work and complexity justifies the benefit of having the feature, without knowing how many people would actually use it in practice.

Most people use this package indirectly as a transitive dependency and never really need to come directly to this repo so I'm unsure of how they'd find this issue to vote on it. In fact, I had to do quite a bit of sleuthing to find this repo myself haha.

What libraries are most people using that use auto-changelog? My assumption was that people were installing and using it directly.

AFAIK, there is no other releaes management library that does it--not even lerna, release-it, or semantic-release, which are some of the most popular release libs out there.

This certainly does make it seem worth investigating. I have a feeling the refactor coming in 2.0.0 (see #142 (comment)) might actually solve this issue already.

[markcellus]

Didn't mean to come off sarcastic. Apologies.

My issue is whether the amount of added work and complexity justifies the benefit of having the feature, without knowing how many people would actually use it in practice.

Did you have any ideas on how we could gauge interest in this feature so that the benefit is justified?

What libraries are most people using that use auto-changelog? My assumption was that people were installing and using it directly.

Sorry, yes they install it directly but use it as a third-party tool that integrates with another tool. See release-it/release-it#545 for an example of how this package is used with release-it.

If #142 (comment) solves this issue, that would be great! 👍

[cookpete]

I've just published 2.0.0. @mkay581 It would be interesting to know if using --append-git-log with this new version enables you to scope a changelog to a directory? git log is now only used for parsing commits between tags, which are fetched separately via git tags.

[ljharb]

@cookpete changelog --append-git-log . doesn't seem to be helping me.

Basically, I've got a new monorepo, with two packages, and nothing's published. I'm trying to publish the first one (so there's no tags at all on the repo yet). My typical approach is these scripts:

"scripts": {
    "preversion": "auto-changelog",
    "version": "auto-changelog && git add CHANGELOG.md",
    "postversion": "auto-changelog && git add CHANGELOG.md && git commit --no-edit --amend && git tag -f \"v$(node -e \"console.log(require('./package.json').version)\")\""
},
"auto-changelog": {
    "output": "CHANGELOG.md",
    "template": "keepachangelog",
    "unreleased": false,
    "commitLimit": false,
    "backfillLimit": false
}

which usually (in 200+ of my single-repo packages) ensures I end up with a tagged commit that includes both the version bump and the changelog. However, in this case, when I run npm version 1.0.0, it generates an empty changelog (as does auto-changelog directly). Any tips?

[cookpete]

@ljharb looks like you're missing --package to use the current package.json as the latest release, which you need when running as part of npm version Something else may be going on though. Let me know if that changes things.

[cookpete]

@mkay581 has gone dark it seems, but I'm hoping scoping to a directory is now possible in 2.0.0 with --append-git-log.

[markcellus]

Oh, I'm no longer using the package. Things have been quite busy for me lately and not sure of when I can get to it. Can it be tested without me?

[cookpete]

Of course. No problem. Just good to know if it works in the wild!