Skip to content

Do not create JavaScript files on errors #828

Description

@kersam-bl

It seems that the TypeScript compiler still produces JavaScript output when the .ts files contains errors:

function testFunc(x: string) {
}
testFunc(1);

Compiling this file gives me an error message:
E:/tmp/typescripttest/Errors.ts(3,1): error TS2082: Supplied parameters do not match any signature of call target:
Could not apply type 'string' to argument 1 which is of type 'number'.
E:/tmp/typescripttest/Errors.ts(3,1): error TS2087: Could not select overload for 'call' expression.

But nevertheless a .js is created.

This seems odd to me. If a compiler reports an error, I do not expect it to create an output file and do as if the compilation would succeed. So the hint which tsc is giving me here is more of a type of a warning: There is something wrong, but the compiler still tries to continue.

Why is this important?
People tend to "ignore" the errors if they are not fatal.
Additionally, this heavily confuses our CI server, since the error just "disappears" on the next build (we do not recompile the tsc if they are older than the resulting JavaScript).

Activity

  1. RyanCavanaugh commented on Oct 6, 2014

    @RyanCavanaugh
    Member

    We definitely want the behavior that the compiler can emit in the presence of type errors. This is a key scenario for migrating existing JavaScript -- you rename some .js file to .ts, get some type errors, but want to keep getting compilation of it while you refactor it to remove the type errors. They are 'warnings' in that sense; we cannot guarantee that your program does not work just because it has type errors.

    That said, we recognize that this isn't always the behavior you want. Incremental builds get messed up by this on a fairly regular basis. We need something to address this scenario.

    The most straightforward thing would be a command line flag (--doNotEmitOnErrors ? Could use a better name) that disables emit if we see type errors, same as how we don't emit if there are parse errors.

  2. danquirk commented on Oct 6, 2014

    @danquirk
    Member

    The compiler error code does now reflect the various possible outcomes of the compilation (ex EmitReturnStatus.JSGeneratedWithSemanticErrors) so it should be possible for tools like grunt-ts to give you some ability to configure your preferred behavior for cases like this (where what you want here is essentially 'warnings as errors').

  3. added this to the milestone on Oct 6, 2014
  4. DickvdBrink commented on Nov 17, 2014

    @DickvdBrink
    Contributor

    This one is fixed and can be closed right?

  5. RyanCavanaugh commented on Nov 17, 2014

    @RyanCavanaugh
    Member

    Yep. Documenting that we merged this in with the name noEmitOnError

  6. locked and limited conversation to collaborators on Jun 18, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    FixedA PR has been merged for this issueHelp WantedYou can do thisSuggestionAn idea for TypeScript

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions