Allow regular flags to mix with --build

[ikokostya]

TypeScript Version: 3.0.0-rc, 3.0.0-dev.20180712

Search Terms:

build mode, --build

Code

I have project with the following tsconfig.json:

{
    "compilerOptions": {
        "module": "commonjs",
        "moduleResolution": "node",
        "target": "es2017",
        "lib": ["es2017"],
        "strict": true,
        "sourceMap": true,
        "noEmitOnError": true,
        "types": ["node"]
    },
    "include": [
        "src/**/*.ts"
    ]
}

and compile it with command:

node_modules/.bin/tsc --build tsconfig.json --outDir out --rootDir /home/kostya/proj/foo

Note, that outDir and rootDir options come from command line arguments, because I want to share output directory for another command (clean).

Expected behavior:

outDir and rootDir options will be took from command line.

Actual behavior:

Compiler ignores this options:

node_modules/.bin/tsc --build tsconfig.json --outDir out --rootDir /home/kostya/proj/foo
message TS6096: File '/home/kostya/proj/foo/--outDir' does not exist.

message TS6096: File '/home/kostya/proj/foo/out' does not exist.

message TS6096: File '/home/kostya/proj/foo/--rootDir' does not exist.

Playground Link:

Related Issues: #25600

[RyanCavanaugh]

Hijacking title a bit.

The current design is intentionally that regular flags don't "mix" with --build. For a single compilation these flags are obviously clear, but it becomes rather fraught with -b -- for example, is the outDir relative to the current directory, or should it be relative to each tsconfig in turn? What does it mean to specify a --outFile for a -b compilation - all projects overwrite the file after each other, or they all get bundled together (and if so, in what order?).

We might opt in specific flags that have clear meanings under a multi-project build -- discussion of which ones you'd like to see and what your use cases are would be useful data. Thanks!

[rrousselGit]

@RyanCavanaugh Parcel uses the transpileModule api to convert ts to js files.

In this situation, how can parcel work with project references to build dependencies too?

[RyanCavanaugh]

@rrousselGit if you're using transpileModule then there's no particular new work to do - transpilation-only mode knows nothing about module resolution or .d.ts inclusion, which are the only things project reference affect.

If you want to read the references from the tsconfig to walk the dependency graph and build upstream projects, you can call ts.createSolutionBuilder and then call getBuildGraph to get a representation of the dependency tree you can traverse.

[dlannoye]

@RyanCavanaugh I ran into this today with other flags like noUnusedLocals and noUnusedParameters. I want these to be enforced in my regular builds, but I would like a way to turn them off when doing watching builds so I can still get run-able output while in the middle of refactoring something where I may be left with unused locals/parameters. With the way build mode works today I can't seem to find a way to accomplish this.

I tried a custom build script that called ts.performBuild with a compilierHost that sets these two options and its seems like they were still ignored. To me this felt like it would be a good option to provide if you didn't want to add all of the compiler flags to build mode cli.

[fkleuver]

The thing is: there is nothing you're "protecting" users against by removing these flags right now anyway. You can simply override stuff in a single tsconfig file. That has always mapped directly to the cli flags, and I think that's how it should stay.

So keep it simple. Let the flags behave just as if it's normal build: only apply them to the build that is called directly. Should one need full control over how all the dependencies are built (which should be rare), simply walk the dependency tree yourself and call them in order with the appropriate overrides. Or just not use --build.

I for one don't care about the potential inconsistency with upstream dependencies. If I want to use the flags and something weird happens, that is my problem.

See my use case in #26763

[jquense]

This is a frustrating situation to be in. We don't use typescript to actually compile code (we use babel) and it's seems very difficult to get a setup using project references that also allows building declaration files.

• We can't use tsc -p . in a package b/c the composite: true means .d.ts files aren't output
• We can't generate them via tsc -b without emitDeclarationOnly, which can only be set in a tsconfig
• setting emitDeclarationOnly in a tsconfig means we can't run tsc --noEmit to typecheck

At this point i've got:

• 1 root tsconfig setting up references
• a base tsconfig with the reference compiler options and others
• 2 tsconfig.jsons per package, one for type checking and one for building

It feels silly, And much of this could be avoided if tsc -b accepted the compiler flags, or had a "type checking only" mode