TS 3.6 officially supports Incremental and Build (aka Project References) APIs: https://devblogs.microsoft.com/typescript/announcing-typescript-3-6/#apis-to-support-build-and-incremental
Support following syntax in tsconfig.json:
{
"compilerOptions": {
// The usual
rootDir: './src',
paths": {
"my-core-lib": ["../core"]
}
},
"references": [
{"path": "../core"}
]
}
By design the composite project that resides in ../core directory will be built before project in cwd.
Using the above setup user can refer to my-core-lib by name (instead of relative paths) from main Next.js project.
my-core-lib is somehow linked to Next.js project's node_modules (via Lerna or Yarn Workspaces).tsc --build --watch and next in parallel, but this will build Next.js project twice and cause other nasty race conditions like failed Next.js build at first when referenced lib is being built (possible solution: tsc --build && (tsc --build --watch & next)). This also needs links in node_modules.No clear alternatives since TS Babel preset just removes types and does not do any actual compilation. I only see several workarounds how we can tell Babel to compile things outside of the main project, this config may be auto-generated based on references.
There's an issue https://github.com/Microsoft/TypeScript-Babel-Starter/issues/35.
None.
Sounds exactly like https://github.com/zeit/next.js/issues/8699. I still don't think we should make this change at this point.
Not exactly. It's option 1 in list of solutions.
Solution 2: use TS APIs to build references, but not Next.js project itself, wait for the references to build and then keep watching.
Solution 3: (does not require any coding at Next.js side but is suboptimal in terms of build performance): use CLI to combine tsc --build and Next.js. It also may result in at least 1 failed Next.js build because of race condition between build pipelines.
im fairly certain they dont intend to properly support typescript. your 2 best options are to:
1) precompile, for example, src transpile to-> app -> '(cli) next app'
2) move your ts files to a workspace package and import the transpiled stuff as single components into pages (so your next project is mostly empty). - this is best imo, but can cause links to become unclickable in your terminal, which is a terrible dev experience
Without references, what is the recommended way to work with monorepos?
So far I came up with this https://medium.com/disdj/monorepo-scripts-strategies-naming-conventions-691c64b51acb
I personally vote for an option when Next.js can internally use TS Build API to initiate build of upstream projects, wait till it's done and then build the Next.js app the regular way (and keep watching the upstream via API), it does not look like a breaking change.
In this case Next.js app itself will only deal with build artifacts, e.g. regular JS files just like if the upstream was NPM published, but internally there will be a way to make sure upstream is built before app.
We're not planning to switch to tsc at this point in time. Babel allows us to do many optimizations that are impossible with tsc at this point in time. It also avoids doing 2 more AST parse and transform runs.