Open m90 opened 6 years ago
I had the same thought. It could live behind a flag so that it's op-in. Would you like to look into this?
I'm kind of unsure whether I'd like to keep the contributors in the package.json
or rather create a separate file for it, like most projects seem to do it 🤔
Sure, I can look into this soon.
A few questions / remarks before doing so:
--contributors
? How would this work for --init
? --init --contributors
?package.json
or CONTRIBUTORS.md
: I'd say both if it's automated anyways. It looks like npm robots take the contributors
field pretty serious, but I think a document kind of like this would be more friendly for humans.--contributors-file
option then? Or could a non-default location then be passed to --contributors
?I think --contributors
is a good option name. I'd say the presence of the option means "enabled with defaults" and --contributors AUTHORS.md
would set the filename. I like your suggested human friendly markdown example. Otherwise the feature could check for the existence of the contibutors
field in package.json
– Would it even make sense to add contributors to both, a markdown file and the package.json
?
Adding this to --init
sound like a good idea, but it might be more challenging. Maybe we go for the flag first and then see how it could work in the context of --init
?
Anyone with a bit of git skills should be able to find the contributors of a project just fine, even when maintainers are forgetful, make mistakes or use imperfect tools.
Alternatively, if a project is hosted on GitHub, one can visit the github home, and see the list of contributors:
https://github.com/facebook/jest/graphs/contributors
I am trying to understand if this feature is necessary.
What value does adding contributors to package.json
or CONTRIBUTORS.md
bring?
I realise this is a very broad question, and not necessarily related to @studio/changes
.
The value in adding contributors to package.json
is that it honors the contributors in the distributed package. I thought npm might do something interesting with this information on their website, but it doesn't look like it.
I used to maintain the list manually in some packages, but I'm loosing interest in doing so. I'm not sure anymore that I actually need / want this feature. Why do we maintain the AUTHORS
file in Sinon btw?
@m90 What do you think?
I don't have any strong feelings about this, but I'd also say it is an adequate way of honoring the contributions you have received over time when distributing your package - in case this is what you want to do.
package.json
does spec people fields, so if you want to include your contributors, it makes it an appropriate tool to express it IMO.
If a maintainer prefers to omit this info entirely, use an AUTHORS
file (apparently npm does read these too), rely on the GitHub contribution graph, or do something completely different is their choice and likely to be nothing that will make or break a project.
If this is a feature that should go into this repo is another question. Seeing this issue is almost 2 years old, maybe it's something that should rather be handled by dedicated tools instead, which can then be consumed by anyone that prefers to have the info in package.json
I also wonder if there are certain licensing scenarios that would mandate including this information in your distribution(s).
Why do we maintain the
AUTHORS
file in Sinon btw?
We just adopted the practice of keeping it up to date. Things were different 10 years ago.
maybe it's something that should rather be handled by dedicated tools instead, which can then be consumed by anyone that prefers to have the info in
package.json
In Sinon we're using the authors
command from git-extras
to maintain the AUTHORS
file.
To be honest, I'd rather remove that dependency in favour of something that is managed with npm
, so we're closer to being able to automate releases on any old CI platform.
I think a dedicated tool that can update either AUTHORS
or package.json
would be great!
When releasing the last mochify version I forgot to add a new contributor to
package.json
and had to do that manually afterwards.Should
changes
do that (which probably wouldn't be too hard to do as everything is already there)? Or should its scope stay limited to the CHANGELOG?