Basic Basic Basic Introduction
Monorepo
Multiple Repositories

Props
Clean ownership
A small team can own and independently develop and deploy the full stack(like tools, workflow, ...etc.) of a service.
Props
Better scale and coordination
The purpose of the organization as a whole gets diluted, each teams don't need to know the main objective of the company.
Teams do not need to coordinate with other teams, only need to know what will be provided by other teams and what should be provided by them.
Thus leading to faster execution.
Props
Narrow clones
Only needs to clone their own repository files
Props
Easily for DevOps
Easily setting CI/CD, ...etc.
Cons
The purpose of the organization as a whole gets diluted, each teams don't need to know the main objective of the company.
Sometimes too idealistic
Assume we have a package called "foo" and there are some related plugins or middlewares
One day, plugin "bar" has some bugs caused by its core package "foo"
Fix foo
Publish foo to npm
Install foo on repository of foo-plugin-bar
Test foo-plugin-bar
foo-plugin-bar still broken
Done
x N

Monorepo
Google
Facebook
Twitter



Props
Simplified organization
With a mono repo, projects can be organized and grouped together in whatever way you find to be most logically consistent, and not just because your version control system forces you to organize things in a particular way.
Using a single repository also reduces overhead from managing dependencies and versions.
Props
Easily refactor
Developers can easily run the entire system on their machine and this helps them understand all services and how they work together. This has led our developers to easily refactor a core feature or find more bugs locally before even sending a pull request.
Props
Single lint, build, test and release process
Since everything is located inside one repo, you can configure your CI/CD and bundler once and then just reuse configs to build all packages before publishing them to remote.
Same goes for unit, e2e, and integration tests—your CI will be able to launch all tests without having to deal with additional configuration.
So does releasing and publishing.
Props
Coding style
Some companies find it useful to have a consistent coding format enforced across their code.
This is certainly more difficult to achieve when you have separated repositories.
Props
Atomic commit
The feature across modules can be rollbacked just like database transaction.
Props
Specific section improvement
With the adoption of mono repo, every individual in the organization is aware of business objectives and this makes it a unified team and hence can contribute more specifically towards the goals and objective of the organization.
Props
Centralized report issues.
People may not clearly know the certainly place where issues belong.
Can use label to distinguish where the issue belongs to.
Cons
Massive repository size
As title
Cons
No way to restrict access authority
Unfortunately, you can’t share only the part of your monorepo.
You will have to give access to the whole codebase, which might lead to some security issues.
Cons
Heavily refactoring
Although easily refactoring as above discussion, but heavily.
Cons
CI CD
Difficultly without tools.
Git Submodules

Git submodules is, for most developers, a painful topic.


Bazel (Google)

Bazel (Google)
Bazel is a build tool for large-scale applications, which can handle multi-language dependencies and support a lot of modern languages (Java, JS, Go, C++, etc.).
In most cases, using Bazel for small-to-medium JS applications is overkill, but on a large scale, it may provide a lot of benefit because of its performance.




Who is using Bazel ?



It's just suitable for really large applications. Thus powerful but hard to learn.
And I haven't use it.
Lerna

Lerna
Splitting up large codebases into separate independently versioned packages is extremely useful for code sharing. However, making changes across many repositories is messy and difficult to track the versions of dependencies.
Problem
Lerna
Commands




Lerna
Centralized version


Who is using Lerna ?


Yarn Workspace

Yarn Workspace
Yarn initially is a dependency manager for NPM packages, which was not initially built to support monorepos.
But in version 1.0, Yarn developers released a feature called Workspaces.
At release time, it wasn’t that stable, but after a while, it became usable for production projects.
Yarn Workspace
Centralized node_modules
Single node_modules folder in the root for all packages.
For example, if you have `packages/package-a` and `packages/package-b`—with their own package.json.
All dependencies will be installed only in the root.
That is one of the differences between how Yarn and Lerna work.
Who is using yarn workspace ?


For packages
Structure, Lerna config, Tools
Structure



package.json
for yarn
lerna
Symlink(Alias)



webpack alias
tsconfig
Clear dependencies



root
packages
Single lint

eslint

prettier

Single build

run topologically via dependencies of packages


bold, highlight, italic, underline, strikethrough
depends on toggle-mark
Single release & publish
add version tag and changelog

publish to npm


For application
Isomorphic & Shared
Isomorphic vs Universal
The backend and frontend share the same code.
Run everywhere

same logic
same logic
Server
Php
Java
.Net Core
Client
JavaScript
Server
JavaScript
Client
JavaScript
Isomorphic
The goal of isomorphic is the same as monorepo
To share
Share anything if possible

DBA
orm
repository
DBA
orm
repository
console client
console client
website server
website
client
Shared in whole app
Isomorphic / common / shared
error codes
utils / helpers (lodash-like)
...etc
Shared in servers
common / shared
dao / entities / models (from orm)
utils / helpers related to business logics for server
middlewares
services, like queue, task schedule, ...etc.
...etc
Shared in clients
common / shared
ui (such as a library)
hooks
utils / helpers related to business logics for client
...etc
Share

Don't repeat your self if possible.
DBA
orm
repository
DBA
orm
repository
console client
console client
website server
website
client
File Structure
For me, it would look like
/isomorphic
/article
/errors
article-not-found.error.ts
/utils
...
...
/db
/article
article.entity.ts
article.repository.ts
...
/server-shared
...
/console-server
/article
article.service.ts
article.resolver.ts
...
/website-server
/article
article.service.ts
article.resolver.ts
...
/client-shared
...
/console-platform
/core
/article
/hooks
useCreateArticle.ts
useUpdateArticle.ts
...
/components
CreateArticleForm
CreateArticleModal
...
/pages
/article
/create
index.tsx
/update
index.tsx
index.tsx
/website
/core
/article
/hooks
useArticleQuery.ts
/components
Article
/pages
/article
index.tsx
Q & A
Monorepo
By jjaayy
Monorepo
- 487