TypeScript: Problem finding modules for starter project

From @jankalfus August 10th

Sometimes when I open my project, VS Code is unable to find imported external modules. I’ve got typings for the modules installed, all files in the project compiles fine using tsc, but I get red squiggly lines in the editor. The weird thing is that I get the squiggly lines only for some .tsx files, while it works for others.

The file src/web/App.tsx is fine: web

While I get squiggly lines for the file src/native/App.tsx: native

My tsconfig.json content is the following:

{
    "compilerOptions": {
        "allowSyntheticDefaultImports": false,
        "jsx": "react",
        "noImplicitAny": true,
        "experimentalDecorators": true,
        "module": "commonjs",
        "target": "es5",
        "rootDir": "src"
    },
    "exclude": [
        "node_modules",
        "src/native",
        "app",
        "app-native",
        "tools",
        "test"
    ]
}

Both react and react-native are installed as global typings.

Unfortunately, I cannot post the source code right now, but basically, the structure of the source files is as following:

src
 |-- common
 |-- native
       |-- index.ts
       |-- App.tsx
 |-- web
       |-- App.tsx
 |-- index.ts (this one is for web)

VSCode Version: 1.4.0
OS Version: Windows 10

Any ideas?

About this issue

Original URL
State: closed
Created 8 years ago
Reactions: 15
Comments: 46 (9 by maintainers)

Most upvoted comments

The tsconfig.json settings are usually the source of the problem: https://www.typescriptlang.org/docs/handbook/compiler-options.html

module sets the output type for your code
moduleResolution sets the way Typescript tries to look for your modules

moduleResolution should be set to 'node' so that it resolves /node_modules/ dependencies properly. Typescript might use this setting automatically depending on what module is set to, but you should set it explicitly to ensure it’s correct.

More info on module resolution here: https://www.typescriptlang.org/docs/handbook/module-resolution.html

manigandham on Mar 28, 2018

Had this same issue this morning. f1 > reload window got rid of the red squiggles for me. Not sure for how long though. (thanks @michaeljota )

ghost on Dec 15, 2017

Edit your “tsconfig.json” with "noImplicitAny": false

dhruvdutt on Jun 2, 2017

@jankalfus

Did you read the documentation regarding resolution? The default now is 'node' which should automatically resolve modules as expected when using npm, however the older setting (and the reasons when it is enabled) is for backwards compatibility.

If you’re starting with a new project, then everything will work fine, but in case you have a different setting for module or have an older project, there will be some extra config needed. Either way I recommend explicitly setting the option to 'node'.

Perhaps Typescript defaulting to 'classic' resolution mode when the output mode is set to ES6 modules was the wrong choice, but it’s all clearly described in the docs. I don’t think reading documentation for the compiler settings is very onerous considering the complexity of Typescript in general and the features it provides.

manigandham on Mar 28, 2018

I wasn’t going to respond, but somehow I fell that if I don’t you will get the felling that you are right, and you are not. A comparison between Babel and Typescript is not only about what is the easier to used, because at the end, Babel is only a transpiler, and Typescript is a complete language. But is not only about that I think.

Babel no longer have presets includes, so no batteries, no fun. You need to include the presets you want to use, and then configure them. While is true that this allow you more control about what you want to use, your point is exactly the opposite.

Babel does not have a type checking system. This is just something that Babel is not. You could, however, use Flow. For sure. But, then you have to configure Flow. And Flow 3rd party libraries. And the Babel-Flow integration.

And what do you mean with buggy anyway? I do have encounter some really edgy bugs, but they all have been reported, and most of them need some underwork first, like conditional typing, that 2.8 have.

So, I’m sorry if you fell Typescript can’t be used for a 5 years old, but I don’t fell like a 5 years old should program with type checkers, maybe with blocks, but not type checkers.

EDIT: I won’t answer you anymore. If you don’t use Typescript, I don’t even know why you are here, but trolling.

michaeljota on Mar 19, 2018

I don’t even understand why the config is necessary for input files. TypeScript should figure everything out on its own.

jankalfus on Mar 17, 2018

@waderyan, @jankalfus, @michaeljota, @roblom,@hysaq @mschnee @farfromrefug, @dhruvdutt, can you link to a minimal repro in a github repo that showcases the issue? Please create the repo with the exact code one would need to see the issue upon opening the directory in vscode (ie: all node_modules are already installed, as it seems there may be a module versioning issue at play).

Without an explicit repro, we can’t make progress on getting a fix in.

aozgaa on Jun 6, 2017

I was having a similar issue, but could resolve it by adding “types” field to package.json of the imported package to specify corresponding *.d.ts file explicitly. (See http://www.typescriptlang.org/docs/handbook/declaration-files/publishing.html) Looks it happens when

trying to import a library compiled with old version of TypeScript without “types” field in package.json
noImplicitAny=true

hysaq on Feb 5, 2017

I don’t know if this still as unsolved problem, but the main workaround here it’s to restart the resolver serve. There is one extension that can do it automatically, and manually. typescript-hero. This will only works with VSCode, and it has to be seen as is, a workaround. So this issue should remain open.

/cc @harshil93 @roblom Hope you find this useful.

michaeljota on Jan 22, 2017

f1 -> reload windows = workaround. 😛

EDIT: @harshil93 sorry. It’s F1. The windows reloading, restart the resolver server.

michaeljota on Nov 28, 2016