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

tsc --build / Project References Feedback & Discussion #25600

Open
RyanCavanaugh opened this Issue Jul 12, 2018 · 77 comments

Comments

Projects
None yet
@RyanCavanaugh
Copy link
Member

RyanCavanaugh commented Jul 12, 2018

Continuation of #3469 "Medium-sized Projects" which has grown too large for GitHub to display comfortably

Please use this thread for feedback, general discussion, questions, or requests for help / "is this a bug" discussions.

Active bugs / PRs in this area:

Possible next steps:

  • (none yet; @andy-ms) Find unloaded downstream projects during rename
  • #25376 Infer project references from monorepo tooling package.json files
  • #25562 Terse mode output for tsc -b
  • (none yet; @weswigham ?) Intermediate build outputs to temp folders
  • (none; stretch) Parallelization / worker processes under tsc -b

Other interesting links:

@timfish

This comment has been minimized.

Copy link

timfish commented Jul 12, 2018

A couple of things:

  1. watch doesn't currently output an initial build. It waits until the first file change. This differs to non build mode.
  2. How is build order determined? I found I had to order the project references in dependency order to get the build to complete first time without error
@RyanCavanaugh

This comment has been minimized.

Copy link
Member Author

RyanCavanaugh commented Jul 12, 2018

@timfish thanks! Re 1 - PR up at #25610. For the other issue, can you sketch out the files you have? The order is supposed to be a simple topological sort that should always yield a correct ordering. I'll try to repro locally in the meantime based on what you've described

Edit: Not sure how to repro - I changed the TypeScript repo's src/tsconfig.json to be in effectively random order and it still figured out a valid build order. Will need details on this.

@EisenbergEffect

This comment has been minimized.

Copy link

EisenbergEffect commented Jul 12, 2018

@RyanCavanaugh Were you all able to land the cross-project rename for the RC?

@RyanCavanaugh

This comment has been minimized.

Copy link
Member Author

RyanCavanaugh commented Jul 12, 2018

@EisenbergEffect we have "upstream" renames (renaming a usage in client affects declarations in shared) but not "downstream" (renames in shared affecting uses in server and client) yet

@EisenbergEffect

This comment has been minimized.

Copy link

EisenbergEffect commented Jul 12, 2018

Gotcha. Any ideas is you'll be able to get the downstream rename in for the final release? or have you already determined that it needs to push out to 3.1 or beyond?

@RyanCavanaugh

This comment has been minimized.

Copy link
Member Author

RyanCavanaugh commented Jul 12, 2018

It looks like we can probably get downstream renames for loaded projects in by 3.0 final. Detecting which other projects on your computer need to be loaded to do an "exhaustive downstream rename" is looking dicey - we haven't found any mechanisms that would let us short-circuit that work when the symbol being renamed is exported from the current file.

@newtack

This comment has been minimized.

Copy link

newtack commented Jul 12, 2018

I am using the API to build Typescript projects, including createWatchProgram and createWatchCompilerHost.

  1. Are these updated to use the new project references and 2) do I need to do anything else in my code other than update the tsconfig.json?
@RyanCavanaugh

This comment has been minimized.

Copy link
Member Author

RyanCavanaugh commented Jul 12, 2018

If you're hosting the compiler API, you don't need to do anything new for project references; everything should work as-is. If you want to take advantage of the new --build mode features, the entry point is createSolutionBuilder and you'll need to provide a BuildHost and CompilerHost along with the file timestamp APIs on the latter.

To migrate to using project references in your code itself, updating your tsconfig.json to a) add references and b) add composite: true may be sufficient - if not, you'll see errors informing you what else needs to happen. Writing a comprehensive migration guide has been a difficult task because project setups are so varied - I'm hoping we can find migrations from early adopters as something to point people to, but it's hard to give guidance without seeing specific build layouts.

@newtack

This comment has been minimized.

Copy link

newtack commented Jul 12, 2018

Thanks @RyanCavanaugh

Are there any examples for "createSolutionBuilder" and "timestamp API"?

@timfish

This comment has been minimized.

Copy link

timfish commented Jul 13, 2018

@RyanCavanaugh ref: Build order.

I'll try to get a repo reproducing this although it won't be until next week.

If I'm just adding all references to a root tsconfig, it should work out the dependency tree from that?

@RyanCavanaugh

This comment has been minimized.

Copy link
Member Author

RyanCavanaugh commented Jul 13, 2018

@newtack the compiler source code itself (src/compiler/sys.ts for timestamp APIs and src/compiler/tsc.ts & tsbuild.ts) are good references.

@timfish

If I'm just adding all references to a root tsconfig, it should work out the dependency tree from that?

Correct

@OliverJAsh

This comment has been minimized.

Copy link

OliverJAsh commented Jul 14, 2018

Trying this out with the 3.0 RC.

declarationMaps
We've also added support for declaration source maps.
If you enable --declarationMap, you'll be able to use editor features like "Go to Definition" and Rename to transparently navigate and edit code across project boundaries in supported editors.

I tried using this but for some reason "Go to Definition" didn't seem to work. I'm probably doing something wrong, but filed an issue with a minimal reproduction case here: #25662

Will this also handle "Find All References"? If not, is there any way that could be supported?

@kohlmannj

This comment has been minimized.

Copy link

kohlmannj commented Jul 15, 2018

Based on @RyanCavanaugh and @rosskevin's work to demonstrate Project References within a Lerna-based monorepo123, I've made another not-for-merging Pull Request which uses both Yarn workspaces and Babel 7: RyanCavanaugh/learn-a#4

Hopefully this example helps others learn! I've been working on a Lerna-based monorepo similar to this, and now (I think) I have a better idea of how to configure Project References with it.

  1. https://github.com/RyanCavanaugh/learn-a
  2. RyanCavanaugh/learn-a#3
  3. #3469 (comment)
@drew-y

This comment has been minimized.

Copy link

drew-y commented Jul 16, 2018

I was hoping to get some advice on how to handle path resolutions. My directory currently looks something like this:

- client/
  - assets/
  - views/
  - src/
  - tsconfig.json
  - webpack.config.js
- shared/
  - src/
  - tsconfig.json
- server/
  - src/
  - tsconfig.json

Im struggling to reference the shared directory. I was surprised to learn that the "paths" section along with baseURL doesn't allow for path aliasing like webpack does. So now I'm not sure how to reference the shared directory at all.

For example, the following doesn't work:

// server/src/index.ts
import { mySharedFunc } from "../../shared/src"

// This doesn't work either. "shared" is still shared after compilation
import { mySharedFunc } from "shared"

Because the project compiles down to:

- dist/
  - client/
    - bundle.js
  - shared/
    - index.js
  - server/
    - index.js

As you can see, it is invalid to reference the src dir as it doesn't exist after compilation.

Should I restructure my repo somehow? Is it possible to get my path aliasing to work?

My struggles appear to be related to #25682

@drew-y

This comment has been minimized.

Copy link

drew-y commented Jul 16, 2018

I've updated my folder structure to have client, server, and shared under one src directory. This resolved my issue.

@aleksey-bykov

This comment has been minimized.

Copy link

aleksey-bykov commented Jul 16, 2018

@RyanCavanaugh any luck with my code? #3469 (comment)

@ryanstaniforth

This comment has been minimized.

Copy link

ryanstaniforth commented Jul 17, 2018

I assumed that with "composite": true, "declaration": true would always be forced. However this only seems to apply with tsc --build.

I found this out while doing a normal build (tsc) and not seeing expected definition files.

Is this expected behaviour? It seems counter-intuitive to me.

@sledorze

This comment has been minimized.

Copy link

sledorze commented Jul 20, 2018

I found myself using the same technique as the references system in our temporary custom incremental build system (comparing d.ts files) to decide what to rebuild in a non incremental scenario.

However, after finding strange results, I've discovered that the typescript compiler (3.0-RC) do NOT generate deterministically d.ts files.
Indeed, when Unions are involded, the displayed order of those seems to depend on the nodeJS run, which makes to system detect false positives.

ex: { status: "400"; body: KoStatus; } | { status: "200"; body: OkStatus; }
vs:
{ status: "200"; body: OkStatus; } | { status: "400"; body: KoStatus; }

I think you may have found yourselves those issues and wonder if that's a know/accepted limitation between runs or if I should open an issue (have not found an existing one yet).

@rosslovas

This comment has been minimized.

Copy link

rosslovas commented Jul 23, 2018

Trying it out on the codebase I'm working on, I ran into a lot of Output file '.../_.d.ts' has not been built from source file '.../_.ts' errors. I managed to strip down a repro to almost nothing, and found that when rootDir and outDir are involved as well as a project reference, source files within an individual project that has a dependency project would be compiled in alphabetical order.

The consequence is that an A.ts that imports from B.ts will fail with Output file '.../B.d.ts' has not been built from source file '.../B.ts' but if I rename A.ts to C.ts everything works, as does removing the project reference or not using root/outDir. The problem occurs in 3.0.0-rc as well as next right now.

Edit: In retrospect this is clearly enough a bug to warrant its own issue, so I made #25864.

@josundt

This comment has been minimized.

Copy link

josundt commented Jul 23, 2018

I just tested TS 3 RC project references in a typical npm package setup with included tests. The tests were set up as a TS project referencing the implementation TS project.

I surprisingly found that project references do not adhere to the outDir compilerOption of referenced or referencing projects, and that the relative paths for module imports in the compiled referencing project's JS files therefore are wrong; paths point to the TS folder, not the compiled output folder.

A somewhat simplified view of my PoC:

  • src/
    (contains implementation code, TS project REFERENCED by tests)
  • dist/
    (compiled output from src/; using the outDir compilerOption)
  • test/
    (tests for implementation code in src/; project REFERENCING src/)

Expected behavior:
Relative paths of module imports in the compiled code for the referencing project should be calculated from:

  • relative path from outDir compilerOption of referenced project
  • relative path from outDir compilerOption of referencing project

I put up a small repository to demonstrate the problem:
https://github.com/josundt/tsprojects-outdirproblem

UPDATE: Separate issue created: #26036

@gentoo90

This comment has been minimized.

Copy link

gentoo90 commented Jul 25, 2018

Is <TypeScriptBuildMode> msbuild parameter pllaned for 3.0.1? It's not working in 3.0.0, tsc.exe still runs with --project, even if it's set to true.

@massimocode

This comment has been minimized.

Copy link

massimocode commented Jul 27, 2018

@RyanCavanaugh This project thing looks really cool so I decided to give it a try. It hasn't been going so well for me so I thought I'd share my experiences and the code-base in case it's helpful for you guys.

Basically, I have the following folders in my project.

  • back-end - A Node.JS back-end. References code from shared.
  • front-end - An Angular 2 front-end. References code from shared.
  • shared - Vanilla JS code. Doesn't reference any of the other folders.
  • specs - Some tests written in typescript. References back-end, front-end and shared.

My previous set-up (TypeScript v2.x) was to have a tsconfig.json in the root with the most "forgiving" settings and that would give my IDE all the intellisense etc and cross project renames. I then had a compile.json in back-end (which was a tsconfig file in disguise), and another compile.json in the front-end (same concept). The reason for these files is that I wanted to only compile front-end code (for webpack) or back-end code (for ts-node) separately from the rest. Needless to say, they wouldn't have any issues picking up the code that I referenced in the shared folder as the paths were all relative etc. This all worked perfectly fine for my work flow and I've been super happy with it (except about a year and a half ago the Angular CLI didn't like it at all, but I'm doing webpack manually and haven't retried since...)

So, I upgraded TypeScript to the @next version and switched over to this whole tsconfig per folder thing and removed the tsconfig.json that was at the root. I'm using the latest version of the VSCode Insiders build, but it doesn't really seem to work at all. In the sense that when I'm looking at some back-end code that references something in the shared folder, it says that thing simply doesn't exist.

The ts-node for my back-end only works if I compile the shared folder and emit to disk, something that I'd rather not have to do because my back-end compiles down to ES6 and my front-end down to ES5. Although I guess it wouldn't be so bad if it emitted declarations only?

Anyway, I've checked it all in, would you mind taking a look and seeing what you think? I wouldn't mind if you wanted to use the repo (or part of it) as some kind of example project. Thanks!

Here's the link: https://github.com/SMH110/Pizza-website/tree/TS_Projects

The previous working setup not using the new projects functionality is at this commit: SMH110/Pizza-website@9548bdd

@yonilerner

This comment has been minimized.

Copy link

yonilerner commented Oct 14, 2018

@RyanCavanaugh I think Im experiencing the same issue as @goloveychuk , where using --watch with --build doesnt seem to incrementally build projects; when a change is detected in any of the projects, only that project is rebuilt, but the entire project is rebuilt, rather than just the changes. --verbose doesnt have any info on this; I'm assuming that this is the case because a recompile upon a change using --build --watch takes about the same amount of time as a full compile of that individual project, 7 seconds, but when running tsc --watch without --build on that project, file changes are recompiled in less than a second

@jonaskello

This comment has been minimized.

Copy link

jonaskello commented Oct 16, 2018

I'm seeing the same thing as @goloveychuk and @yonilerner. I tested on a small project that just takes ~3 seconds to build but I'm seeing that tsc -w -b takes ~3 seconds for the initial build and then also ~3 seconds for every file change while tsc -w -p takes ~3 seconds for the initial build and then ~0 seconds for file changes:

$ tsc -b -w --preserveWatchOutput packages/pkg1

15:44:42] Starting compilation in watch mode...
[15:44:45] Found 0 errors. Watching for file changes.
[15:44:48] File change detected. Starting incremental compilation...
[15:44:50] Found 0 errors. Watching for file changes.
[15:45:12] File change detected. Starting incremental compilation...
[15:45:15] Found 0 errors. Watching for file changes.

vs

$ tsc -w --preserveWatchOutput -p packages/pkg1
[15:45:29] Starting compilation in watch mode...
[15:45:33] Found 0 errors. Watching for file changes.
[15:45:36] File change detected. Starting incremental compilation...
[15:45:36] Found 0 errors. Watching for file changes.
[15:45:38] File change detected. Starting incremental compilation...
[15:45:38] Found 0 errors. Watching for file changes.

Looking for som clarification if this is the intended behaviour of tsc -b -w or if there is a plan to make it behave like tsc -w -p?

@RyanCavanaugh

This comment has been minimized.

Copy link
Member Author

RyanCavanaugh commented Oct 17, 2018

@yonilerner @jonaskello sounds like a bug, though we've had some recent improvements in this area as well that may have addressed it. If you have a repo we can use to test on, we can investigate?

@sheetalkamat

This comment has been minimized.

Copy link
Member

sheetalkamat commented Oct 17, 2018

We do not yet do incremental build at program level in tsbuild watch mode (Like tsc -w) and it’s a todo yet to be addressed and that’s the reason you see that much time to build

@yonilerner

This comment has been minimized.

Copy link

yonilerner commented Oct 17, 2018

@sheetalkamat Ah ok, that would explain it. Thanks for the info. Do you have an idea of when that will be implemented?

@jonaskello

This comment has been minimized.

Copy link

jonaskello commented Oct 17, 2018

@sheetalkamat Nice to know that this feature is coming :-). Currently it is not really tenable to use tsc -b -w during development for larger projects because it is so much slower than tsc -w -p or ts-loader. Of course I'm also interested to know the roadmap for implementing this.

@ciddan

This comment has been minimized.

Copy link

ciddan commented Oct 17, 2018

Hey,

We've run into an issue with project references that we can't quite figure out. I'll try to explain the scenario, it's not entirely straightforward.

These are the relevant parts of our monorepo project structure:

platform/
    client/
        ui/
            tsconfig.json
    shared/
        libs/
            ui/
                vuex-extensions/
                    tsconfig.json
    web/
        thing/
            tsconfig.json

client/ui and web/thing both reference shared/libs/ui/vuex-extensions. All three projects depend on the npm module vuex. The vuex-extensions project contains some vuex helper decorators.

When we import the vuex-extensions shared library into the client/ui project or the web/thing project those projects stop successfully compiling, due to the following reason:

import Vuex from "vuex";
import { createDataStore } from "@shared/vuex-extensions/DataModule";

Adding the import statement for the vuex-extensions changes the import Vuex from "vuex" module resolution. Instead of importing from the "local" node_modules, "vuex" is resolved to the shared lib. And it seems as if the ambient type declarations present in the vuex typings aren't applied in this scenario.

See following screenshots:

import_1
import_2

We've found a work-around by forcing the typescript compiler to use the correct path for vuex by adding it to the paths section of our tsconfig:

"paths": {
	"@shared/localization-store": [
		"../../shared/libs/ui/localization-store"
	],
	"@shared/vuex-extensions/*": [
		"../../shared/libs/ui/vuex-extensions/dist/*"
	],
	"vuex": ["node_modules/vuex"]
},

I'm not sure if this is a bug in the module resolution, intended behavior, incorrect usage or all three at once. Any help on the matter would be appreciated. Thanks!

@sheetalkamat

This comment has been minimized.

Copy link
Member

sheetalkamat commented Oct 17, 2018

@ciddan you can use --traceResolution to see what is going on with the resolution in both cases for further investigating

@sheetalkamat

This comment has been minimized.

Copy link
Member

sheetalkamat commented Oct 17, 2018

@yonilerner @jonaskello the --watch behavior change is likely to come in 3.3

@ciddan

This comment has been minimized.

Copy link

ciddan commented Oct 17, 2018

@sheetalkamat Thanks for the tip! I'll check that out tomorrow.

@axelnormand

This comment has been minimized.

Copy link

axelnormand commented Oct 24, 2018

I'm also struggling to get project references working as expected with a react lerna monorepo project. The idea is to have a publishable component library as used by app1 and app2 but all in one monorepo and share build tools.

Here's a working example: https://github.com/axelnormand/react-typescript-monorepo

I couldn't get it to work in VS Code without also adding that paths bit in the tsconfigs like @ciddan mentioned.

As also mentioned up thread, VS Code can't compile it out the box as the parent projects need the generated d.ts files, so looking forward to future versions when you don't need declaration and declarationMap on.

My solution for VS Code was to use tasks.json to call compile:watch npm target (which just calls tsc -b). Then when VS Code starts up you have to press ctrl+shift+b to get it going:

"tasks": [
    {
      "type": "npm",
      "script": "compile:watch",
      "problemMatcher": ["$tsc-watch"],
      "isBackground": true,
      "group": {
        "kind": "build",
        "isDefault": true
      }
    }
  ]

So my actual question is why do i need paths as well as references?
Paths is then also needed to plugin in to ts-jest settings

ps Thanks for all the great typescript work so far though as love developing react/react native with it.

@unional

This comment has been minimized.

Copy link
Contributor

unional commented Oct 28, 2018

I get xxx is not in project file list error when enabling composite:

tsconfig.json

{
  "compilerOptions": { "composite": true, ... },
  "files": [ "src/index.ts" ]
}

Before enabling, this would work as tsc will follow the dependencies in src/index.ts.

After enabling, all files referenced throws an error:

error TS6307: File 'xxx' is not in project file list. Projects must list all files or use an 'include' pattern.

If I have to include src, this causes all test files next to the source files included in the build.

Is this a bug? If so, should I file it separately? 🌷

@andrewbranch

This comment has been minimized.

Copy link
Member

andrewbranch commented Oct 29, 2018

@unional from what I understand, this is intentional; not a bug:

All implementation files must be matched by an include pattern or listed in the files array. If this constraint is violated, tsc will inform you which files weren’t specified

(from https://www.typescriptlang.org/docs/handbook/project-references.html#composite)

I believe this constraint helps tsc figure out the project dependency tree more quickly/easily. You might find include more convenient than files, and it works best when projects are grouped into folders.

@sheetalkamat

This comment has been minimized.

Copy link
Member

sheetalkamat commented Oct 29, 2018

Right now we only use declaration maps to jump to source files instead of declarations. Its working as intended at moment but could change in future. #25844 will handle out of date declaration maps to not crash.

@agDmitry

This comment has been minimized.

Copy link

agDmitry commented Nov 11, 2018

There is a caveat using project references.

Imagine monorepo setup with packages A and B where A is dependent on B. In tsconfig of A there is a reference to B.

Now when i want to use a different version of B in A (that version will be downloaded from npm) i get in a situation where A references version of B that is located in monorepo but actually uses version of B that is downloaded from npm. This can cause many troubles by providing wrong typings info.

@screendriver

This comment has been minimized.

Copy link

screendriver commented Nov 16, 2018

@yonilerner @jonaskello the --watch behavior change is likely to come in 3.3

Great! The current behavior is especially annoying when you want to run unit tests in watch mode.
Because tsc --build --watch in combination with project references compiles every file again (instead of just the changed ones) and updates the timestamp on every compiled output file. That leads to running the watched unit tests multiple times because every project in my project references gets updater one after another.

@dgreene1

This comment has been minimized.

Copy link

dgreene1 commented Nov 18, 2018

It seems quite unworkable if true that with project references you can only resolve from the index, not direct to a file e.g.

Just wanted to share that this seems like a good thing that you can't use things that weren't made "public." I think of it as an enforcement of no-submodule-imports from ts-lint: palantir/tslint#3051

The ability to prevent coupling future proofs a team like mine without having to resort to separate repos or microservices with brittle CI/CD pipelines.

Anyway, I'm really looking forward to these features. Great work @RyanCavanaugh and the team! TypeScript makes coming to work every day an absolute joy! :)

@pd4d10

This comment has been minimized.

Copy link

pd4d10 commented Dec 31, 2018

How to make tsc --build always emit output files, whether or not there is an error?

It is different from tsc at this point.

Tried to set noEmitOnError: false, but seems not work

@yonilerner

This comment has been minimized.

@sgronblo

This comment has been minimized.

Copy link

sgronblo commented Jan 23, 2019

I've now spent a whole day trying to get the following set up to work. I have a small "monorepo" test repository that contains three "projects" (I've seen many other users mention having similar structures):

  • common
  • frontend -> depends on common, should be built by webpack
  • backend -> depends on common, ideally I would like to be able to build a docker image from this with the required node_modules included

Requirements:

  1. I would like to be able to use yarn workspaces for this but that presents its own challenges in filtering out the node_modules that belong only to the backend project. I guess it's best to keep that part out of this discussion.
  2. I would like to be able to import common with an absolute import like import * as common from "common" so that in the case that we would ever split common out of the monorepo we wouldn't need to fix all the paths.

One of the main questions I have now is how do "project references" interact with "path mappings". I noticed that if I put

paths: {
  "common": ["../common/src"]
}

I am able to do the relative import of common/src/index.ts from backend/src/server.ts through the above mentioned import * as common from "common" however this also gives me the ability to jump immediately to an implementation inside common, even when I don't have declarationMaps turned on for common.

Does that mean that accessing the code through a path mapping bypasses project references and I won't get the speed benefits?

@jonaskello

This comment has been minimized.

Copy link

jonaskello commented Jan 23, 2019

@sgronblo I use yarn workspaces in a similar setup and it works well. I don't use any path mappings as they become redundant. However to make it work you cannot use any typescript plugins in webpack, instead just let webpack build/watch the JS files that tsc --build produces. In tsconfig.json make sure to set "outDir": "lib", and "rootDir": "src" for all packages. In package.json also make sure to set "main": "lib/index.js"and "types": "lib/index.d.ts".

I would also recommend that you prefix your own packages with a group name, something like @myapp/common, @myapp/frontend etc. This is only for the name field in package.json. You still keep the folder structure like myapp/packages/common, myapp/packages/frontend etc. Then when you run yarn it will create linked folders in node_modules/@myapp so it is easy to find your packages under node_modules. Becuase of these folder links import * from @myapp/common will just work without any path mappings as the common behaviour is to look upward for node_modules/{packagename}.

Also something I noticed is that it is important to set references correctly in tsconfig.json. If the packages build in incorrect order they will not find each other. For example if frontend builds beforecommon it will not find it as it is not built yet. So there must be a reference from frontend to common.

@spion

This comment has been minimized.

Copy link

spion commented Feb 7, 2019

One big blocker we still have for build mode is the requirement that declarations are turned on.

In our monorepo we have multiple "toplevel" packages (several backends, several frontends) that are not libraries, and they share multiple dependencies.

The backends and frontends cannot have declarations turned on. It would be a huge amount of unnecessary busy work to do it, to eliminate a bunch of TS4058 s i.e.

Return type of exported function has or is using name 'X' 
from external module "/path/to/external/module" but cannot be named.

This in turn means we cannot add them to the composite project. As a result, they somehow have to be built and watched separately from "build mode" which complicates the whole setup and negates the benefits for large subset of our code.

Perhaps build mode could take several toplevel (composite) project configs at once as an argument? That way we can make one per backend/frontend and pass them all.

@screendriver

This comment has been minimized.

Copy link

screendriver commented Feb 13, 2019

With the latest version v3.3.3 we still have the issue #25600 (comment)

tsc --build --watch builds every project (all files within that project) where I changed a single file instead of just that one file. Is that now the expected behaviour?

@SimenB

This comment has been minimized.

Copy link

SimenB commented Feb 13, 2019

Using this in Jest now while migrating from Flow to TypeScript. My only real complaint constructive feedback is that it's slow (emitDeclarationOnly currently takes a full minute on my beefy 15" 2018 MBP, and we're not done migrating so it'll keep increasing).
It'd be really nice if TSC provided some sort of progress meter. Some sort of 213123/123123123123 thing that updated whilst it was building would be awesome (similar to progress in webpack or yarn).

Incremental builds are fast (and watch works great), though!

@lo1tuma

This comment has been minimized.

Copy link

lo1tuma commented Feb 13, 2019

Seems like 7b290fd introduced this behavior to update all last modified timestamps of all output files of a project even if the contents didn’t change. I don’t quite understand the explanation in the commit message and why this is necessary.
Running tsc --build -w --listEmittedFiles confirms this assumption, after changing a single file it lists all files within the project as being emitted.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment