Cannot find imported modules (Angular)

[jtsom]

Opening up a new Angular application, created with the Angular CLI causes many Diagnostic messages saying it can't find any of the modules - @angular/core, @angular/platform-browser, etc.

[nickbclifford]

Looks like it can find all the other npm packages that I use in my Angular projects, so my guess would be that it's something to do with scoped npm packages. For now, I'll have to switch back to atom-typescript until this issue is resolved.

[yubaoquan]

I met the same problem.

What's more, it also reports that some file is not a module but actually the file is module.

And some “property does not exist on value of type” errors. Consider such situation:

someObj = someFn()
if (someChecker.isTypeFoo(someObj)) {
    const propertyPOfFoo = someObj.p // will got an error: property p doesn't exist on value of ...
}

However, atom-typescript doesn't report those errors.

[wyqydsyq]

I've also experienced this with the uuid package. I have the package itself and it's @types/ package installed, my app runs perfectly (tsc itself can recognize the dependency) but ide-typescript incorrectly reports an error.

[wyqydsyq]

Happens for react and ramda in another project as well with a slightly different message, even though both are very definitely installed, and both tsc and atom-typescript do not report these incorrect errors.

[wyqydsyq]

In the case of that second project I just realized that the package.json and node_modules is located above the path that the "Project Folder" in Atom is open, so it looks like perhaps ide-typescript isn't looking above that path e.g.

./
  - node_modules ← This is where my modules are installed
  - package.json
  - src/
  - apps/
    - myapp/ ← This is the active "Project Folder" in Atom
        - index.tsx ← This is where I'm editing

[damieng]

There is definitely a 1-to-1 mapping between the folder you open in Atom and the folder the language server takes as it's initial project folder.

Does it work if you open ./ in your example?

[wyqydsyq]

Opening the Node.js (where package.json, tsconfig.json and node_modules are) project context as the Atom Project Folder works like in the screenshot above.

atom-typescript is able to correctly use the right context in this scenario so I feel like the issue is that this plugin is sending the Atom Project Folder path as the context to the language server, when in reality it should be sending the Node.js/TS project path to the language server. The language server should be receiving the same context path (~/Projects/unity/core_portal) even when I have a sub-directory of it as my active Atom Project Folder (~/Projects/unity/core_portal/apps/pulse_portal), because said sub-directory does not have a package.json, tsconfig.json or node_modules of it's own.

Rather than just sending the Atom Project Folder directly to the language server, check if it has a tsconfig.json, if it doesn't, then it is not a TypeScript package so does not make sense to send this context to the language server, in this case, traverse up the file tree from the Project Folder's path until a tsconfig.json is found, when it is, the directory it's found in is the context to be sent to the language server.

[damieng]

There's all sorts of issues to consider when we do this;

1. Do we stop at the first one up the tree or keep going?
2. Do we scan down the tree in every folder for additional possible tsconfig.json's?
3. Do we fire up an entire language server for every match we find both up and down?

I suspect this is going to be a per-ide-package process we have to consider and whether there is a combination that will satisfy the majority of people (and how do we handle the less popular scenarios)

[wyqydsyq]

I think what you mentioned in 1 is the behaviour that tsc and atom-typescript both appear to follow, it is also similar to how Node.js normally behaves with looking for package.json and node_modules/ when resolving modules.

As far as I can tell, atom-typescript (which works perfectly for my use case) only ever has one "active" tsconfig.json at any given time, which can be opened by clicking the little . in the status bar:

[CodinCat]

I have the same problem in a JavaScript (not TS) project when @ts-check is enabled

Only npm modules. Relative path imports work correctly.

[tudorbarbuhc]

Nothing yet on this one?

[wyqydsyq]

atom-typescript, which works fine in this scenario, appears to work by only using a single tsconfig.json, based on the "current file" (focused tab) for context at any given time.

So I imagine ide-typescript would function just as well by operating in the same way.

Only send the tsconfig.json for the current active file to the language server. When the user changes context (e.g. opens another file, switches tabs, focuses a file in another pane) evaluate the path of the tsconfig.json for the new current file, if it's different to the previous one then pass the path for the new one to the language server and ideally if possible, get the language server to unload the previous one.

The only potential downside I see to this approach is that it would prevent users from seeing errors from files in a different tsconfig.json context to the currently active file, which I think would be preferable anyway because seeing errors not relevant to the current context would be confusing. You wouldn't see those errors from running the active file via tsc so I shouldn't see them in Atom by opening that file in a tab.

[nickbclifford]

Any updates on this?

I have this problem when opening atom with atom ., however it works correctly when atom is opened with atom ./.

I would expect both to have the same outcome.