Ember-cli-typescript: [v2.0] tsconfig with Isolated Modules doesn't like the environment.js file

[happycollision]

Please paste the output of ember -v here

ember-cli: 3.5.1
node: 10.14.1
os: darwin x64

Please paste the output of tsc -v here

Version 3.2.2

Please paste your tconfig.json and tslint.json or eslint.json (if applicable) below

My tsconfig.json

{

  "compilerOptions": {

    "target": "es2017",

    "allowJs": true,

    "moduleResolution": "node",

    "isolatedModules": true,

    "allowSyntheticDefaultImports": true,

    "noImplicitAny": true,

    "noImplicitThis": true,

    "alwaysStrict": true,

    "strictNullChecks": true,

    "strictPropertyInitialization": true,

    "noFallthroughCasesInSwitch": true,

    "noUnusedLocals": true,

    "noUnusedParameters": true,

    "noImplicitReturns": true,

    "noEmitOnError": false,

    "noEmit": true,

    "inlineSourceMap": true,

    "inlineSources": true,

    "baseUrl": ".",

    "module": "es6",

    "paths": {

      "isolated-modules-error/tests/": [

        "tests/"

      ],

      "isolated-modules-error/": [

        "app/"

      ],

      "": [

        "types/"

      ]

    }

  },

  "include": [

    "app//",

    "tests//",

    "types/*/"

  ]

}

What are instructions we can follow to reproduce the issue?

ember new sample; cd ./sample 
ember install ember-cli-typescript@next 

ember s 

What did you expect?

I expected to not see any type errors right off the bat.

(I did expect a build error, because I haven't yet installed babel, but the type error I am reporting occurs regardless of babel understanding TS. This is just the minimum number of steps to reproduce.)

What happened instead?

TypeScript complained about this:

config/environment.js:1:1 - error TS1208: Cannot compile namespaces when the '--isolatedModules' flag is provided.

1 'use strict';
  ~~~~~~~~~~~~

I tried:

1. removing 'use strict', but then it just complains about module.exports.
2. changing that environment file to a TS file with and export, but that failed to run my after it was built.

So the type error is preferable, but just letting you know that the out-of-the-box types are confused about that env file.

[chriskrycho]

We shouldn't even be compiling this at all. I'm not sure how or why it's ending up in the pipeline. @dfreeman any thoughts?

[dfreeman]

It looks like it's because of the relative import in the default test-helper.js in new projects. I'm not sure why the blueprint uses a relative import instead of an absolute one there, but because that happens to point to the actual path on disk of the config.js node module, TS is attempting to actually resolve that file.

Playing around locally, changing that to an absolute import (<app-name>/config/environment) or flipping allowJs off in tsconfig.json prevents TS from trying to load the file at all. @chriskrycho do you remember why we default to allowJs: true?

[chriskrycho]

IIRC it's because the language server also uses that and you need it set to true to get it to resolve correctly across the TS/JS boundary for mixed codebases.

[dfreeman]

Ahh, that makes sense.

We might consider just turning isolatedModules back off by default for 2.0 projects. It's recommended for anyone using Babel for transpilation, but in practice it doesn't actually seem to catch usage of many of the problematic constructs, so it may be more trouble than it's worth.

[happycollision]

For what it is worth, isolatedModules happens to be the reason I am getting errors (that I simply ignore) on some of my @types packages. Like @types/jquery. I didn’t mention that originally because I thought there was a chance it was “my fault” for those.

[chriskrycho]

Fixed by #511 (now live as part of v2.0.0-rc.2). Thanks again for the report!