-
Notifications
You must be signed in to change notification settings - Fork 448
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upgrade to use Typescript 3 project references #15
Comments
One subtle but incredibly useful benefit of project references is logically being able to map your input source to its outputs. If you’ve ever tried to share TypeScript code between the client and server of your application, you might have run into problems controlling the output structure. Notice that we ended up with a copy of shared in both client and server. We unnecessarily spent time building shared twice and introduced an undesirable level of nesting in The problem is that TypeScript greedily looks for Creating a |
So I think your // ./packages/web/tsconfig.json
{
"compilerOptions": {
// Needed for project references.
"composite": true,
"declaration": true,
// Other options...
"outDir": "../../dist/web",
"strict": true,
"module": "esnext",
"moduleResolution": "node",
},
"references": [
{ "path": "../common" }
]
} |
So the advantage of setting this up is I can run build once and it will build each project? |
It's a feature specifically geared towards mono repos, where a main project contains multiple projects and some projects share code from common modules. Speeds up build time, incremental builds (diffs), shared code and control over output for shared code... Super awesome!! |
Typescript project references
SD Times article
"references were one of the biggest improvements of the release, making it easier for developers to share dependencies between multiple TypeScript projects by allowing
tsconfig.json
files to reference each other.“Specifying these dependencies makes it easier to split your code into smaller projects, since it gives TypeScript (and tools around it) a way to understand build ordering and output structure,” Rosenwasser wrote. “That means things like faster builds that work incrementally, and support for transparently navigating, editing, and refactoring across projects. Since 3.0 lays the foundation and exposes the APIs, any build tool should be able to provide this.”
Perfect for a Mono repo :)
The text was updated successfully, but these errors were encountered: