Ok, I’ve been figuring out how to organize our codebase and looking at how other developers do this. Here is a bunch of thoughts I had.
- sources (
- routers (
- settings (
These plugins will be some utilities for the WordPress.org REST API. It could be a monorepo as well but I don’t know if it is better in this case. I prefer to start developing each plugin in its own repository.
The same as before but with WordPress themes.
examples & tutorials
These examples are intended to show how to use frontity in a project, so it makes sense to maintain a different repository for each example, right?
The repository for the organization’s webpage.
Why to use a monorepo?
Extracted from Babel docs
- Single lint, build, test and release process.
- Single place to report issues.
- Easier to setup a development environment.
- Easy to coordinate changes across modules.
- Tests across modules are run together which finds bugs that touch multiple modules easier.
- Codebase looks more intimidating.
- Repo is bigger in size.
npm installmodules directly from GitHub
How can we do it?
Currently, we can implement a monorepo in two different ways:
This is the tool most people are using. It seems that
Lernacan be used with
conventional-changelogand that would be awesome! Here is a tutorial on how to do that.
Using yarn workspaces and
We could adopt this implementation and wait for
semantic-releaseto add support to monorepos in the meantime. Here is an issue to follow their progress on that.
People using a monorepo
- Gatsby - https://github.com/gatsbyjs/gatsby
- Next - https://github.com/zeit/next.js/
- Babel - https://github.com/babel/babel
- Jest - https://github.com/facebook/jest
- emotion - https://github.com/emotion-js/emotion
- styled-components - https://github.com/styled-components/styled-components
People not using a monorepo
- Webpack - https://github.com/webpack/webpack