Next.js: TypeScript 3.6 Incremental and Build API Support

Created on 11 Sep 2019  路  7Comments  路  Source: vercel/next.js

Feature request

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

Is your feature request related to a problem? Please describe.

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.

Describe the solution you'd like

  1. Ideally, since Next.js now offers first-class support of TS, it can use TSC instead of Babel, but as I see, it can have performance problems as well as backward compatibility issues. And obviously it will require effort.
  2. Alternatively, as a limited support MVP, we can use new TS APIs to build references only (and watch them too), not the main Next.js project, which still will be built using Bebel. This implies that my-core-lib is somehow linked to Next.js project's node_modules (via Lerna or Yarn Workspaces).
  3. Worst case scenario is to run 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.

Describe alternatives you've considered

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.

Additional context

None.

All 7 comments

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?

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.

Was this page helpful?
0 / 5 - 0 ratings