ide-typescript
ide-typescript copied to clipboard
atom
Cannot find imported modules (Angular)
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.
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.
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.
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.
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.
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
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?
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.
There's all sorts of issues to consider when we do this;
- Do we stop at the first one up the tree or keep going?
- Do we scan down the tree in every folder for additional possible tsconfig.json's?
- 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)
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:
I have the same problem in a JavaScript (not TS) project when @ts-check is enabled
Only npm modules. Relative path imports work correctly.
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.
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.
There should be a work-around for this in the next update: https://github.com/atom/ide-typescript/issues/55#issuecomment-349431488
With that update you can disable the warnings from this plugin and use the old atom-typescript plugin to get your TypeScript warnings, this may result more memory/cpu consumption as the tsc compiler might be getting ran twice, but at least you should be getting accurate TypeScript warnings while also getting all the lovely developer experience features provided by ide-typescript.
My understanding is that in order to fix this issue ide-typescript (this project) needs to find the tsconfig.json file using the same approach as both tsc and atom-typescript.
Is this a large fix? Why can it not be included in the next release? Will existing projects suffer from this change?
I also feel that the above work-around does not address the issue. I did not install ide-typescript to use along with atom-typescript I installed it to use as a standalone Typescript ide.
@BrianDGLS it addresses the issue by providing a band-aid means to achieve the same end result (accurate TS warnings in your Diagnostics tab while still getting all the IDE features of ide-typescript) as resolving the issue would. Obviously it's a suboptimal solution because it requires use of an extra plugin but it does provide an effective work-around until a proper fix is implemented. It addresses the issue, but doesn't resolve it.
I'm not very familiar with the language server, but it appears to be designed to be used in a way where everything gets loaded initially (e.g. upon opening a project in your editor) rather than on-the-fly loading and unloading on-demand, there may be some changes required upstream to support this use case for TS if it doesn't play nicely with this more "lazy" strategy of providing context.
Have there been any language server or ide-typescript updates that resolve this issue other than the (rather hacky, might I add) work-around?
Disabling and re-enabling both ide-typescript and atom-typescript solved this error for me
@tylerFowler That fix was merged June 3 2017. This issue is more recent than that.
This project is using an older version of the upstream server so that fix night work. This needs to be bumped from 2.7.0 to 2.9.3
On Wed, Jun 13, 2018, 12:32 AM Brian Douglas [email protected] wrote:
@tylerFowler https://github.com/tylerFowler That fix was merged June 3 2017. This issue is more recent than that.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/atom/ide-typescript/issues/43#issuecomment-396842612, or mute the thread https://github.com/notifications/unsubscribe-auth/AAHQp882UsuDICI-57T1CQbQi0TKc4H1ks5t8MASgaJpZM4Pint8 .
I'll take a look at getting the TypeScript language server dependency updated this week
Possibly fixed with the new ide-typescript 0.8.0 update - let us know.
No change for me.
@dctalbot
Disabling and re-enabling both
ide-typescriptandatom-typescriptsolved this error for me
but.. without that you're not able to see the linter errors in real time..right? is there no solution to this already?
