Strict mode runtime error without warning

With the following tsconfig.json:

{
    "compilerOptions": {
        "target": "es5",
        "module": "amd"
    }
}

The following file:

if( true ) {
    function foo() {}
}

export = foo;

Compiles with no errors or warnings, and emits:

define(["require", "exports"], function (require, exports) {
    "use strict";
    if (true) {
        function foo() {
        }
    }
    return foo;
});

This, however, results in a runtime error in Firefox, because in strict mode, function declarations may not appear within if blocks.

I believe this should cause a compiler error, or at very least, a warning.

This caused an issue on our production website today. When we updated our TypeScript compiler, our code, which was working without "use strict", stopped working (without any warning or build issues). I'm currently trying to make sure nothing else broke because of "use strict", but the lack of warnings makes finding these issues difficult.

[adidahiya]

FWIW this was listed as a breaking change in 1.8 here.

@adidahiya Yes, but that link also states:

This shouldn't have any visible changes in most code as TS considers most strict mode errors as errors at compile time, but it means that some things which used to silently fail at runtime in your TS code, like assigning to NaN, will now loudly fail

In this case, it's causing code to fail that didn't fail before. I'm not saying this code should work, I'm just saying it should be an error or warning.

One of reasons we use TypeScript is that we can catch more issues at compile time rather than runtime.

[mhegazy]

The compiler can not statically catch all the strict mode issues. there are ones that are dynamic.
the issue you listed of inner function declarations should be caught by the compiler, so this is a bug.

for the breaking change in 1.8, consider using --noImplicitUseStrict to revert back to pre-1.8 behaviour

[use-strict]

@mhegazy , this is not only a breaking change, but one that happens at runtime, which is totally unexpected and hard to debug, since it's an error generated by transpiled code, hidden behind source maps.

The legacy app that I'm working on also had problems after upgrading to 1.8, because of global variables:

import 'something';

declare var someLegacyGlobal;

someLegacyGlobal = true; // <-- fails at runtime, no error at compile time

@use-strict, to be fair, in this instance you told the compiler via your declare statement that someLegacyGlobal was already declared. It could not, therefore, have warned you about it.

[use-strict]

@errorx666 , I see your point, but the problem is still that the compiler allows something which would result in a runtime error. The "noImplicitUseStrict" compiler flag is an OK workaround, it's just very hidden. For instance, using "Symbol" in ES5 target results in a compiler error and I would expect this case to be no different.

Because the issue itself is in conflict with the ES6 spec, I see no way to fix it other than make it an explicit compile time error and disallow the "declare" keyword inside ES6 modules. However, this would make globals unusable and require yet another compiler flag for "compatibility" that would relax this check (e.g. nonStrictModules).

I would have expected to be able to use window.someGlobal as a workaround, but typescript currently complains there is no someGlobal variable in the Window interface. Not sure about this behavior.

I would have expected to be able to use window.someGlobal as a workaround, but typescript currently complains there is no someGlobal variable in the Window interface. Not sure about this behavior.

Two options:

1. window[ 'someGlobal' ]
   2:

declare global {
  interface Window {
    someGlobal: any;
  }
}

[use-strict]

1. Would not be type-safe. Also looks like Window no longer has an index signature.
2. That's the augmentation feature from 1.8 I assume. I didn't know it was possible to do it with global scope as well. Seems to work OK. I assume this affects the whole project not just the current file.

[mhegazy]

As noted earlier, --noImplicitUseStrict should revert to the pre-1.8 behavior and not inject a "use strict" in your modules.

[kitsonk]

(from #7339)

This is an issue, even when you don't have modularlized code. For example, even when you provide the "use strict"; prolog, TypeScript does not properly realise scoping of the function:

'use strict';

if (true) {
  function bar() {
    console.log('bar');
  }
}

bar();

In ES5 strict mode, it disallows block scoped functions. In ES6 strict mode, it allows block scoped function, but in both cases, bar() is not available and TypeScript should disallow this. Essentially it always considers that function scoping is non-strict mode.