as open source maintainer:
I like normal "Merge" the most.
- It keeps git history of the author.
- It works great when multiple authors work on a PR.
- git blame shows a smaller commit. More likely to understand what's the change intent.
- git bisect finds bugs easier.
- Easier to remove a part of the PR.
Author should feel free to squash logical related commits in her/his PR.
- You lose information.
- Difficult to fix a PR based this PR or a intermediate state of it.
- You rewrite commits.
- Difficult to fix a PR based this PR or a intermediate state of it.
I don't like to have commit messages in a specific format.
- It should be easy to write the message.
- A PR author probably don't know how about your format.
- Asking her/him to rewrite the commit message could be difficult. Not everybody is a git expert.
- Commit message can't be wrong, because it's not relevant for the process
- You don't need an extra tool to make a commit
- Relevant information can be put into the PR. It's easily editable and can have a template. It also includes discussion.
- Minimium work required to write and merge PRs.
I like github reviews.
I don't think an extra tooling is needed here.
I don't like to use a separate tool for releasing.
I like this command: npm version patch && git push && git push --tags && npm publish
- It's simple. No setup needed. Works on every repo.
- It creates tags in git and npm.
- It fails if your local branch is not up-to-date.
- It fails if you have uncommited changes.
- You can manually fix-up every part of the process. Custom version, npm tag, etc.
- You have to check CI manually before cutting a release. But probably you already have a notification in place if CI on master fails.
I don't like automatic publish to npm.
I think it's not nessecary (at least for npm packages).
Just use webpack/webpack#master
in your package.json
dependencies
to get the bleeding edge version.
I don't like to leak my npm credentials to github or travis.
I like to publish static sites automatically to gh-pages.
I think it's only relevant if you expect many commits.
I like to write the change manually.
I don't like a CHANGELOG.md file.
I like github releases.
I like to write the changelog in one go.
- You can omit unimportant messages
- You can merge multiple commits (i. e. a PR fixing another PR)
- You can add details to important stuff, i. e. steps for migration, links to documentation
- You can edit the changelog if there was a typo in it
- You don't have to rewrite git history to fix the changelog
- Less context switching for interleaving changelog writing with coding. Only changelog work on release.
- Fewest duplications
- CHANGELOG.md would duplicate github releases
- generating changelog from git history would duplicate git history in changelog
- Details history: git history
- Summarized changelog: github releases
I like integration tests over unit tests.
- You get more for your time!
- Refactoring is easier.
- While refactoring it's less likely that you have to change the tests.
- It's more likely to write correct integration tests than unit tests.
- Integration tests can be used as examples for users.
I think they are useless.
I like using labels and milestones instead.
- Too many clicks
- Duplicated information
I don't like to add many labels.
If issues have more the 3 labels I think that something is wrong. Remove labels!
In my opinion most useful labels:
bug
it's a bugmerge it
PR is fine, could be merged if CI passesbreaking change
PR that as breaking changestests needed
PR that need tests- Label for PRs another Contributor should take care of
- Labels for issue where everybody can do a PR (easy one)
I like to assign important issues to the next milestone.
I like to assign important PRs to the next milestone.
I like to close issue if issue template is ignored.
I don't like trying to solve problems when information is incomplete.
I don't like to answer questions that many other people could answer. -> Stack Overflow
I don't like to write node.js code that need to be transpiled before use.
- Extra step, extra source of errors
- Slows down development
- Debugging is more diffcult
- Coverage is more difficult
- People that want to contribute may not know your transpiled language
- Don't assume everybody knows or likes Typescript or ES2021
It's fine if you need to bundle anyway, i. e. when writing code for the browser.
I like CI.
- Travis is great to linux test and general tests
- Travis is slow for OSX build. Don't do more than 1 OSX build per commit.
- Configure travis to only build master branch and PRs to reduce travis load.
- Appveyor is great to Windows test. But it's also slow, because it only does one build at a time. Not as slow as travis for OSX.
- Configure appveyor to only build master branch and PRs to reduce appveyor load.
- CircleCI cannot replace travis, because it doesn't support matrix builds.
- CircleCI can be used to fast feedback for PRs.
I think people don't read CI results for their PRs.
I like to copy relevant CI log seqment into the PR comments.
I like code coverage.
- codecov.io great, very detailed info
- Can be configured to require 90% coverage on PR diffs
- coveralls.io great, less detailed but fine
- It breaks when doing too many builds in short time (you get no result)
I don't like github teams.
I like contributors on the repo settings.
I like teams only if they affect multiple repos that are connected.
I like if only one person is responsible for release and publish.
I like to assign only one person for merging PRs. (not always possible)
- Teams need too many click to configure for each repo
- Similar structure of repos and teams is an antipattern
- Teams can't be moved between orgs
I like to enable master as protected branch.
I like required status checks: travis, appveyor, coverage (patch > 90%).
Note: If it is also enforced for admins your can't push a new release commit
I like to disable "Squash to merge" and "Rebase to merge".
In theory: If there are 4 units/modules with 3 edge cases in each, you would write 12 unit tests. If you write integration tests for those 4 units/modules, you must be aware of edge cases of all of them and potentially write 3^4=81 tests to cover edge cases. With integration tests, it's too easy to slip edge cases, where bugs usually occur. Integration tests usually test trivial functionality.
If you are refactoring in such a way that public interfaces of some units/modules change tremendously, obviously you need to rewrite unit tests.