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

Compile 3rd TypeScript modules with loose checking mode. #23275

Closed
zheeeng opened this issue Apr 9, 2018 · 1 comment
Closed

Compile 3rd TypeScript modules with loose checking mode. #23275

zheeeng opened this issue Apr 9, 2018 · 1 comment
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@zheeeng
Copy link

zheeeng commented Apr 9, 2018

TypeScript Version: 2.8.1

Search Terms:
tsconfig + node_modules / compile third module

Tried solutions

set 'skipDefaultLibCheck', 'skipLibCheck', 'moduleResolution' fields in tsconfig.compilerOptions;
set 'exclude', 'include' fields in tsconfig;

Code

Given an example 3rd module viser(viserjs/viser) which are also written in TS. Its package.json defines types field guide tsc to reference 'src/index.ts' under its project root. The lib contains unused locals, unused parameters, implicit any (and we can even assume it contains some totally incorrect type assignments).

And the working project is written in strict mode, its compile configs have severely conflicts with the 3rd module which is written in loose mode. Are there any ways to compile them without error throwing?

Even though we can make tsc output compiled js files ignoring tsc errors, in create-react-app project, build by react-scripts-ts script, any compiling errors will be printed in the terminal and the dev page overlay.

import viser from 'viser'  // a loose checking lib

// strict mode code below

Expected behavior:

The 3rd modules under node_modules are compiled in loose mode, not throw any errors. Our main
project is compiled in strict mode, throw conflicts with tsconfig rules.

Actual behavior:

Compiling throw errors.

@mhegazy
Copy link
Contributor

mhegazy commented Apr 10, 2018

The 3rd party package is exposing its sources as output. that is wrong. it should be a .d.ts.

Exposing the sources of a package means you want every user to compiler and include that in their output. i.e. distributing code. in this case the errors are correct.

I suggest filing an issue against viser to use a .d.ts instead.

@mhegazy mhegazy added the Working as Intended The behavior described is the intended behavior; this is not a bug label Apr 10, 2018
@zheeeng zheeeng closed this as completed Apr 10, 2018
@microsoft microsoft locked and limited conversation to collaborators Jul 25, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug
Projects
None yet
Development

No branches or pull requests

2 participants