← Wed, Sep 23 digest

The GitHub wiki is an anti-pattern (2022)

read article ↗ hn thread ↗

summary

GitHub Wikis are an anti-pattern because they separate documentation from the source code, breaking the critical link between versioning and content. Keeping documentation in a /docs folder within the main repository ensures that docs evolve with the code and undergo the same rigorous review process. This approach leverages existing developer tools and automation, making the maintenance of documentation more sustainable and professional. Ultimately, the minor convenience of a wiki's accessibility is far outweighed by the loss of version control and peer review.

key points

  1. Documentation stored in a /docs folder is versioned alongside the code, allowing users to easily access the correct documentation for older versions of the software.
  2. Using a repository folder enables documentation edits to go through the standard pull request process, ensuring high quality through peer review and automated linting tools.
  3. Storing docs in the repo allows contributors to use their preferred local IDEs for editing and keeps the documentation available offline after cloning the project.

who should read it

Software developers and project maintainers who are deciding how to organize their project documentation on GitHub.

discussion positive

consensus

Commenters generally agree that monorepos are the ideal choice for small to medium projects due to lower overhead and better localization of changes. While some argue that monorepos become unwieldy at massive scales, others contend that polyrepos introduce their own significant synchronization and dependency management burdens. Ultimately, the group views the choice as a trade-off between different types of complexity rather than a clear-cut victory for one approach.

top insight

The discussion reveals that many monorepo advocates base their views on Google's success, yet often overlook the immense custom tooling Google built to make such a scale possible. Without similar resources, developers may find themselves stuck with a 'creaking' monorepo that is too critical to migrate but too large to handle efficiently. This highlights that scale is measured by the number of parts and teams rather than just disk size.

Generated by an LLM from the article and thread. Check the sources before relying on it.