Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

best ts eslint setup for large monorepo?#8506

Closed
Feb 19, 2024· 1 comments· 7 replies
Discussion options

Our monorepo is quite massive, and I wanted to share some statistics from the tsc to give you an idea of the scale:

Projects in scope:                         35Projects built:                            33Aggregate Files:                       116237Aggregate Lines of Library:           1202224Aggregate Lines of Definitions:       8076544Aggregate Lines of TypeScript:         956954Aggregate Lines of #"auto">To ensure code quality, I've been exploring options for linting within our monorepo. I've referred to the documentation (link), but I still have a few questions.
Switching to one root tsconfig.eslint.json (seeOne root tsconfig.json)
Since each package has its own compilerOptions, I'm unsure about the configuration details. Can someone provide guidance on the compilerOptions for the root tsconfig.eslint.json file?
Using a shell script to only lint one package at a time, using your existing config above.
It is helpful if we have enabled EXPERIMENTAL_useProjectService?
You must be logged in to vote

Replies: 1 comment 7 replies

Comment options

Context: in my day job work on a repo with >90k TS files.

At that scale it's unfortunately a physical impossibility to use the ESLint CLI out-of-the-box.

  • ESLint itself scales linearly with the number of files because it runs single-threaded and synchronously.
  • TypeScript similarly scales poorly because it too is single-threaded and synchronous.
  • There are a few rough edges to the integration between ESLint and TypeScript and the larger the project the rougher those edges get.
  • ESLint itself just doesn't support many of the concepts that we need to describe the shape of a codebase to make things work.

You can make it all work - however you will need to build out some infra based on your company's setup. For example you can build a layer on top of ESLint that runs each "package" in its own thread to isolate it and its memory from one another.

At Canva we don't use type-aware linting from the CLI because our repo doesn't have a nice "package" structure that would lend itself to clean isolation across threads. Instead we lint our files by roughly partitioning files acrossos.cpus().length-1 workers.

We do have some type-aware lint rules turned on via a custom TypeScript Language Server Plugin whose code is forked fromthis project. But we don't enforce type-aware rules at CI/CLI lint time.

You must be logged in to vote
7 replies
@Zzzen
Comment options

Have you also experienced the issue of unresponsiveness in the tsserver and constant loading in the IDE as our TypeScript codebase grows larger? It seems that IntelliSense functionality is also not working most of the time.

@bradzacher
Comment options

Yes - typescript IDE performance scales horribly with the size of the codebase.

In particular it's the size of the dependency graph of the currently opened file(s) that impacts the performance. There's no way around this either because the TS server is single-threaded and it relies on the.ts source files, not the.d.ts files.

The best bet is to try and architect your codebase to keep dep graphs shallow where possible.

@matthew-dean
Comment options

I can't remember where I saw this, but I saw a tip that the root tsconfig.json should NOT include all files of a monorepo, because it will suffer. It should only include the root TS files you need to lint (if any), and should explicitly exclude any of the packages that will extend the root tsconfig.json.

So:

The best bet is to try and architect your codebase to keep dep graphs shallow where possible.

I can confirm this makes a HUGE difference in monorepos, and a lot of monorepo guides will not mention this.

@kirkwaiblinger
Comment options

@matthew-dean

To clarify, is this aligned withthe TS docs on project structure or suggesting something different? I am personally running into issues along the lines of this discussion so I'm curious what concretely you've found to be beneficial

@kirkwaiblinger
Comment options

Another reference on this topic:nx's guide

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Labels
None yet
4 participants
@Zzzen@matthew-dean@bradzacher@kirkwaiblinger
[8]ページ先頭
©2009-2025 Movatter.jp