-
-
Notifications
You must be signed in to change notification settings - Fork 881
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Split changelog into files by version #3284
Conversation
9710ba4
to
8f2b9d0
Compare
const unreleasedChangelog = 'changelog/UNRELEASED.md'; | ||
const templateChangelog = 'changelog/_EXAMPLE.md'; | ||
|
||
const version = metadata.version; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe check if newChangelog exists first?
I guess this is to make it easier to automate maintenance of the change log? That's pretty cool. Worth noting though that there are a couple minor disadvantages to this approach:
These are all definitely solvable problems though:
|
I like the sound of that idea. I set up the known issues page on the upcoming res.com in a similar fashion: http://reddit-enhancement-suite.github.io/knownissues/
Good idea! And a pointer to res.com, too. |
@@ -27,7 +29,8 @@ | |||
"lint-fix": "eslint . --fix", | |||
"test": "cross-env NODE_ENV=test ava", | |||
"coverage": "cross-env NODE_ENV=test nyc ava", | |||
"report-coverage": "nyc report --reporter=text-lcov | coveralls" | |||
"report-coverage": "nyc report --reporter=text-lcov | coveralls", | |||
"version": "babel-node build/version.js" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might want to use postversion
for this, so that build/version.js
isn't using the old version when creating the changelog file. Although, I guess that might mess up the tagging? Hmm... does this work the way I'm imagining it does?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, version
is what we want to use. preversion
has the old version number, version
has the new version number and is before the commit (which we want to add to), and postversion
is after the commit
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, really? Somebody needs to tell npm to update their docs:
preversion, version: Run BEFORE bump the package version
😜
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh. Haha. They just did: npm/npm@c565d89
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Huh, I'm surprised that's not deployed yet (I guess only on a new npm release?).
The npm version
docs go into more detail and seem to be correct:
- Run the version script. These scripts have access to the new version in package.json (so they can incorporate it into file headers in generated files for example). Again, scripts should explicitly add generated files to the commit using git add.
16c0b27
to
73b1411
Compare
@@ -0,0 +1,30 @@ | |||
/* eslint-disable import/no-commonjs, import/no-nodejs-modules */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess import/no-commonjs
can be removed now since you're using ES6 imports?
and make version changelog file from
changelog/UNRELEASED.md
when runningnpm version
.