1

● Tech Lead, Software Engineer
● The Grammarly Editor
● Grammarly browser extension (past)
● @grammarly/focal contributor
Oleksii Levzhynskyi

2. The limitations that we've faced
Agenda
4
1. Why use monorepo?
3. Short intro to Bazel
4. Almost real-world example of webapp with
Bazel
5. Results and conclusions

https://app.grammarly.com

@g/utils @g/textarea @g/editor @g/webapp
Why use monorepo?
6

Alarm!! Vulnerability in
tests dependency!!!
@g/utils @g/textarea @g/editor @g/webapp
Why use monorepo?
7

Alarm!! Vulnerability in
tests dependency!!!
@g/utils @g/textarea @g/editor @g/webapp
Why use monorepo?
8

1 2 3
Why use monorepo?
All changes in one MR One place for all configs
No need to repeat
configuration or project setup
(CI/CD, pull request config,
dev config, so on)
No abandoned packages
No long chains of MR to
update one line

Monorepo v1: yarn workspaces + wsrun
10

Monorepo v1: CI
Build
Deploy to
stagings
Verify
Reports
(danger, custom
e2e reporter)
units
linters
e2e
11

Monorepo v1: CI
Build
Deploy to
stagings
Verify
Reports
(danger, custom
e2e reporter)
units
linters
e2e
integration
performance
a11y
business
metrics
12

Monorepo v1: Dependency management
dep1 (tsc)
dep2 (rollup)
dep12 (tsc)
dep3 (webpack)
webapp_1
webapp_2
13

.segnahc elif rof gnihctaW
14

15

Monorepo v1: No caching/smart rebuilds for affected changes
16
Build on CI was ~50 minutes even for “isolated” packages (Ex:
scripts for release or e2e tests)

New packages should not affect average build
time (ideally)
Build only things that matter
build tools as a dependency
Remote execution
The new Architecture
Not only JS

18
utils
build:esm build:cjs
specs licenses
core-functions
build:esm build:cjs
specs licenses
webapp
build:esm build:cjs
specs licenses
app for modern browsers
Build only things that matter!

Custom scripts
yarn workspaces/lerna
Microsoft rush
Existing tools
Bazel

Bazel is a mature framework with huge community and stable
architecture
20

bazelbuild/rules_nodejs
21

Bazel intro

Basics: commands
23
bazel build
bazel run
bazel test

Basics: pure builds; the “unix philosophy”
Sources Output_1
Build
Output_1 web app
Build
24

Basics: macros and starlark language
25

Project structure
26

Build-specific configs
- package.json
- tsconfig.cjs.json
- tsconfig.esm.json
- webpack.config.js
Integration with IDE
- package.json
- tsconfig.json
BUILD.bazel as a source of truth
27
BUILD.bazel

What about “configs”?
28

Example project

Example project: simplified version of OnlineEditor
1. [TODO] build app with webpack
2. [TODO] tests
3. [TODO] dev-server for app
30

load("@npm//webpack:index.bzl", “webpack")
Webapp (app.grammarly.com)
31

Webpack build
32
packages/webapp/BUILD.bazel

33
bazel build //packages/webapp:webapp

load("@npm//jest-cli:index.bzl", "jest_test")
Tests with jest
34

Tests with jest (official example)
35
tools/jest/index.bzl

Tests with jest (official example)
36
tools/jest/index.bzl

bazel test //packages/webapp:test
37

38
yarn bazel test //...

Build tool as a dependency
39
tools/webpack/index.bzl
packages/webapp/BUILD.bazel

Example project: simplified version of OnlineEditor
1. [DONE] build app with webpack
2. [DONE] tests
3. [TODO] dev-server for app
40

Dev-server
41
tools/webpack/index.bzl

ibazel run //packages/webapp:serve
42

ibazel run //packages/webapp:serve
43
+
webpack plugin to avoid watch conflicts

Need more speed!
44

incremental build with
webpack
Super fast with Bazel “worker mode” protocol
45
webpack dev build
serve files (es-dev-server or similar)

Real world results:
○ time of the cold build on CI: wasn’t really changed
○ time of the hot build on CI: 2 minutes, was 10 minutes (5 times as fast!)
○ time of the hot start locally: 5 seconds, was 4 minutes (~50 times as fast!)
○ dependency builds automatically without additional code changes
○ no packages with broken scripts in packages.json
46

Example project: simplified version of OnlineEditor
1. [DONE] build app with webpack
2. [DONE] tests
3. [DONE] dev-server for app
47

48
+
typescript build for “utils” package
https://github.com/oleksiilevzhynskyi/bazel-web-monorepo

It’s scalable! It’s fast! It works!
49

Not like other front-end build tools
It’s a challenge to wrap some front-end tools into Bazel
as they use “conventions over configuration” approach
Challenges The learning curve is high

Need caching
When to use it?
51
Huge monorepos with complex dependency
chain
Some parts should be build on specific env

Thank you
52

53
devua.club //uncomment
BASIC Programming stream
Grammarly Engineering Digest: Sign Up Here

Join us at Grammarly
54