silvermine/eslint-config-silvermine

TypeScript: `strict` rule error forces function form of 'use strict' in non-module files

yokuze opened this issue · 3 comments

In .ts files only: when a file is not a module (i.e. there are no imports and no exports), the strict rule throws an error when attempting to use the global (at the top of the file, no IIFE required) form of the 'use strict' statement:

'use strict';

function testing(): boolean {
   return true;
}

let b = testing();

// eslint-disable-next-line no-console
console.log(b);

This fixes it:

(function() {
   'use strict';

   function testing(): boolean {
      return true;
   }

   let b = testing();

   // eslint-disable-next-line no-console
   console.log(b);

}());

but we don't want to have to wrap our files in IIFEs.

This is an error in typescript-eslint-parser that should be fixed soon.
https://github.com/bradzacher/eslint-plugin-typescript/issues/255
eslint/typescript-eslint-parser#583 (comment)

Basically, strict rule behaves completely differently for modules and for scripts. The example above would be parsed as a script because the parser is set to auto detect the sourceType and the example file doesn't import or export.

That being said, I think we really need to consider turning off the strict rule all together for TypeScript. We already enable the strict option in our base ts config, which outputs the 'use strict' directive at the top of our outputted files, In addition, once the sourceType setting is honored, we'll get an error for any TypeScript file that does have a 'use strict' directive.

error  'use strict' is unnecessary inside of modules  strict

Also, we have a custom rule for banning script style TypeScript files that was never enabled.

From our decisions document:

  • Do we need to do something to make sure that all files are file modules?
    • IOW, what if someone writes a file that neither imports nor exports something? Now any vars in the files are contributing to a global namespace, which we don’t want. Would that happen in any real-world scenarios? If so, can we block it with linting or compiler flags?

That's a good point. I agree, the use strict eslint rule could be turned off for TypeScript files.

Fixed with #32 (24794ea)