Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

type-coverage-core itself is incompatible with default tsconfig #78

Open
FauxFaux opened this issue Feb 16, 2021 · 3 comments
Open

type-coverage-core itself is incompatible with default tsconfig #78

FauxFaux opened this issue Feb 16, 2021 · 3 comments
Labels
enhancement New feature or request fixed and released

Comments

@FauxFaux
Copy link

Version(if relevant): 2.14.9

I'd like to use type-coverage-core from our test framework in node. Unfortunately, the import style used in the project is incompatible with the recommended node tsconfig, targeting commonjs without esModuleInterop. A script which uses type-coverage-core causes the whole project's build to fail, as:

node_modules/type-coverage-core/dist/core.d.ts:1:8 - error TS1259: Module '"/home/faux/code/snyk/registry/node_modules/typescript/lib/typescript"' can only be default-imported using the 'esModuleInterop' flag

1 import ts from 'typescript';
         ~~

  node_modules/typescript/lib/typescript.d.ts:7204:1
    7204 export = ts;
         ~~~~~~~~~~~~
    This module is declared with using 'export =', and can only be used with a default import when using the 'esModuleInterop' flag.

node_modules/type-coverage-core/dist/interfaces.d.ts:1:8 - error TS1259: Module '"/home/faux/code/snyk/registry/node_modules/typescript/lib/typescript"' can only be default-imported using the 'esModuleInterop' flag

1 import ts from 'typescript';
         ~~

  node_modules/typescript/lib/typescript.d.ts:7204:1
    7204 export = ts;
         ~~~~~~~~~~~~
    This module is declared with using 'export =', and can only be used with a default import when using the 'esModuleInterop' flag.

This can't be ignored with ts-expect-error, but can be worked around with dynamic requires.

It isn't as simple as switching it to the commonjs compatible (but still safe) import syntax, as that's incompatible with your module target.

I humbly request that you switch to targeting commonjs, and disable esModuleInterop, to make the module easier to use from a node application, which I assume to be the most common usecase?


I'm currently working around this by not installing type-coverage-core, // @ts-expect-erroring the import, then installing it just to run with ts-node. npx also fails for us, absolutely no idea why; maybe another bug report when I rule out the rest of our system.
skipLibCheck also works, if you're happy with that.


% cat tsconfig.json
{
  "compilerOptions": {
    "target": "esnext",
    "module": "commonjs"
  }
}
% cat index.ts
import { lint } from 'type-coverage-core';
lint;
plantain-00 added a commit that referenced this issue Feb 16, 2021
@plantain-00
Copy link
Owner

v2.15.0 should fix this.

@voxpelli
Copy link

voxpelli commented Feb 17, 2021

Just a note: esModuleInterop: true is the recommended config, though the legacy mode of false is what one gets if one leaves it out

@FauxFaux
Copy link
Author

FauxFaux commented Feb 18, 2021

Interesting. Maybe worth adding it to https://github.com/microsoft/TypeScript/wiki/Node-Target-Mapping too.

I think we have it turned off because of some compatibility problem with some mocking library, although who knows if that has been fixed over the last years.

Edit: Oh, and 250+ compile errors for turning it on, of course. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request fixed and released
Projects
None yet
Development

No branches or pull requests

3 participants