TS2590: Expression produces a union type that is too complex to represent - VIM

Question

I am using typescript-vim

I have typescript installed globally npm install -g typescript

My project's package.json shows "typescript": "^5.1.6"

If I run :!tsc --version in vim, 5.1.16 is shown.

This SO question and this issue report and this SO post all point in the direction of discrepancies between the TS version in the project and the TS version being used by the compiler.

1. how can I confirm whether or not there is indeed a discrepancy in vim?
2. how can I configure typescript-vim to use the typescript version specified in the project?
3. are there other reasons for this error? Here is a bit of the code:

        const apiParams = {...a, ...queryArgs} as any;
        apiQuery(apiParams, postData)  // <----------------- error is here
            .then((response: AxiosResponse) => {

I can try to provide more context if needed but most of the answers seem to point to TS version issues, rather than actually addressing something in the code. Annoyingly, the error does not appear when opening the project in VSCode.

Answer 1

Installing Npm packages globally can be justified if those packages are standalone tools that you could use outside of a project context. In a project context, it is actually vital to only use the project's tools.

If you don't, your formatting will be different, your linting will be different, and your compiler will throw errors that your collaborators won't get. That is, if your project even runs.

The plugin in question reinforces bad practices by a) using global tsc by default and b) doubling down on it in the README.md.

IF your problem is effectively caused by having two different tsc versions, then you should be able to work around it by telling the plugin to use the local version, as per the documentation:

let g:typescript_compiler_binary = 'npx tsc'

npx is part of Npm, see $ npm help exec. Basically, npx will try to run local tsc first, then global tsc if local tsc is not found, then ask you if you want to download it if global tsc is not found.

--- EDIT ---

Problem solving is a tree with a functional error as its root: you expect procedure A to have outcome A but you get outcome B. From there, you try a bunch of different paths, branching out for every possible cause, hoping that one of them will be THE ONE.

The core issue, here, is that you get a compiler error in Vim that others on your team don't have in VSCode.

Now, one of the branches of the problem solving tree is that, perhaps, the mismatch between the global tsc and the local tsc could explain that error, which means that you have two problems:

1. the compiler error,
2. and the compiler mismatch.

The question is 90% about the latter and, thank you for that, 10% about giving context by mentioning the former.

This answer addresses the mismatch issue as well as it could, by showing you how to configure the plugin you mentioned to use the local tsc.

If that plugin is actually involved, then the proposed solution solves the mismatch problem. But there is no guarantee that the compiler mismatch problem is the cause of the compiler error problem.

Now that the compiler mismatch problem is solved, it happens so that the compiler error problem persists. This means that you must backtrack to the parent branch of the problem solving tree and try something else.

On your way, you can mark the compiler mismatch problem as solved by clicking on that tick.

Now, your problem involves a number of parts:

• the editor,
• the editor plugin/subsystem that calls the external compiler,
• the global compiler,
• the local compiler,
• the local tsconfig,
• and your code.

You can strike out the editor because all it does is relay the plugin's information to the user, without any knowledge of your code or the TypeScript spec or whatever.

The plugin comes next, but all it does is relay the errors thrown by the compiler. Therefore it should probably be stroke out as well.

The compiler used by your plugin is the one throwing out the error so this is where you should start. React projects are never built with tsc directly. They are built with some kind of Webpack or Rollup or whatever wrapper that may or may not use tsc under the hood. Therefore, it is possible that your use of tsc is unwarranted. Maybe you shouldn't use tsc directly to begin with? How can we now?