Build does not find errors when targeting ES5 with latest TypeScript version

[HermannGruber]

TypeScript Version:
3.5.0-dev.20190529

Search Terms:

target es5 array prototype include
appdata roaming

Code

Background: As explained here
TypeStrong/ts-loader#941

I have modified an example typescript example file from that repo by adding a line of code that uses array.prototype.includes, and modified the tsconfig.json to target es5.

Update
I found that the following steps can be used to reproduce the issue without resorting to the ts-loader repository or any other tools.

• create a root folder
• download package.json from here and put it into your root folder
  https://github.com/TypeStrong/ts-loader/blob/v6.0.2/package.json
• run yarn install
• create folder "example"
• create folder "example\src"
• put file package.json into the "example" folder, with the following content

{
  "name": "vanilla",
  "main": "index.js",
  "version": "1.0.0",
  "scripts": {
    "build": "webpack --mode production",
    "start": "webpack-dev-server --mode development --progress --color"
  },
  "devDependencies": {
    "ts-loader": "5.0.0",
    "typescript": "3.2.1",
    "webpack": "4.0.0",
    "webpack-cli": "3.0.0",
    "webpack-dev-server": "3.1.14"
  }
}

• cd into "example\src"
• put files "tsconfig.json" and "render.ts" into that folder, with contents as follows.
  The file tsconfig.json reads:

{
    "compilerOptions": {
        "sourceMap": true,
		"target": "es5"
    }
}

The file render.ts reads:

function render() {
    document.getElementById('wrapper').innerHTML = "<h1> Hello World!</h1>";
    var foo : boolean = "foobar".includes(":"); 
}

export = render;

• run yarn install
• install latest version of typescript (or any other version starting with 3.2.1) by running
  npm install -g typescript@next
• run tsc --listFiles

Expected behavior:

Since the target is es5, I expect the following compiler error:

src/render.ts(3,34): error TS2339: Property 'includes' does not exist on type '"foobar"'.

Note that the system behaves as expected if I install TypeScript 3.1.1:
npm install -g typescript@3.1.1
and run
tsc --listFiles

Actual behavior:

The output contains the following lines, which seem to be the reason that "includes" can be resolved.

C:/Users/hermanng/AppData/Roaming/npm/node_modules/typescript/lib/lib.es2015.d.ts
C:/Users/hermanng/AppData/Roaming/npm/node_modules/typescript/lib/lib.es2016.d.ts
C:/Users/hermanng/AppData/Roaming/npm/node_modules/typescript/lib/lib.es2017.d.ts
C:/Users/hermanng/AppData/Roaming/npm/node_modules/typescript/lib/lib.es2018.d.ts

When switching the global install to TypeScript version 3.1.1 these lines are not emitted.

[HermannGruber]

Update If I remove the following devDependencies from the package.json in the root folder (i.e. not the package.json in the nested folder), the TypeScript Compiler behaves as expected.

    "@types/micromatch": "^3.1.0",
    "@types/node": "*",
    "@types/semver": "^6.0.0",
    "@types/webpack": "^4.4.30",

Notice that this is the package.json used/owned by ts-loader. I am still clueless what happens here and why.

[jonschlinkert]

If I remove the following devDependencies

Did you remove one at a time to narrow it down, or all at once? Do all of them need to be removed to fix the issue? (I maintain micromatch, so I'm interested in what's going on in case it's something I need to triage, even though it's the @types/micromatch package)

[HermannGruber]

@jonschlinkert many thanks for your hint at narrowing it down! I gave it a try. I need to remove both node and webpack to fix the issue. That is, the issue persists as long as the type definitions for node or webpack are referenced (did not try all 16 combinations, though). Also, if only @types/micromatch or @types/semver stays, it behaves as expected. Do you happen to have an idea what might be going on there?

[sheetalkamat]

Seems like ts3.2/node definition includes reference to these libraries

[sheetalkamat]

@DanielRosenwasser @RyanCavanaugh @rbuckton What behavior is expected here. Node's index.d.ts contain reference to lib files that are not targeted by the compiler Options and that results in the descripencies.

[rbuckton]

That is because the NodeJS definitions are designed to describe the types of their corresponding NodeJS version, and NodeJS supports these. This is the intended behavior.

If the NodeJS types are being included by a dependency and are being automatically picked up, you can specify a "types" entry in tsconfig.json.