jsconfig Not Picked Up When tsconfig is Present

[mjbvz]

From: microsoft/vscode#26550

TypeScript Version: 2.3.3

Repo
Create a folder that contains both a tsconfig.json for ts files and a jsconfig.json for js files

Expected behavior:
Both projects are picked up

Actual behavior:
Only the TSConfig is picked up

[mhegazy]

That is actually by design. tsconfig.json is always given preference, and if it is not applicable it is skipped. i would like to get more user input on this before making a decision whether to change the current design or not.

[mjbvz]

Thanks @mhegazy.

Can you take a look at microsoft/vscode#26550 (comment) and see if there are other ways to address the issue @TripleSnail was running into

[firelizzard18]

@mhegazy I use different compilers for JS and TS so it's pretty frustrating that I can't specify the compiler options separately.

[gersongoulart]

I have a large project written in Javascript that we want to migrate to TypeScript. The process will be slow and take a long time but meantime all import aliases are broken on javascript for this reason. It'd be nice if VSCode would implement aliases on both file types or at least fallback to jsconfig.json on .js files.

[kallebornemark]

I have a mixed JS/TS codebase, and I need to specify a paths object in order to get my Webpack aliases to work with VS Code, but I don't want to display TS errors in JS files. Is there way to achieve this?

My first thought was to have a both a jsconfig.json and a tsconfig.json, but apparently having the former present is the same as specifying allowJs: true in the latter?

[mohammadalipak]

I have a mixed JS/TS codebase, and I need to specify a paths object in order to get my Webpack aliases to work with VS Code, but I don't want to display TS errors in JS files. Is there way to achieve this?

My first thought was to have a both a jsconfig.json and a tsconfig.json, but apparently having the former present is the same as specifying allowJs: true in the latter?

Ya VSCode will ignore jsconfig.json when tsconfig.json is present. The way to make paths resolution (or aliases) work is to simply set allowJs: true in tsconfig.json and delete jsconfig.json as it won't be used.

See: microsoft/vscode#41890 (comment)

[infacto]

Same here. I use tsconfig because it's a TypeScript project. But also have Node scripts in JavaScript and want the "checkJs" feature. In subfolder "tools", it works. But I also have some js-files in root. I think both files can work since one config file is for ts-files and the other one for js-files. ... I don't want tsconfig allowJs. It's a different setup. 🤔

[AlfishSoftware]

If both jsconfig and tsconfig are present in the same folder, then at least jsconfig should apply for .js files in globs excluded by tsconfig but matching the jsconfig. Currently these appear as "No jsconfig" in VSCode.

It's only logical that you'd want a source TS project parallel and separate from the target compiled JS project. Having allowJs: true in tsconfig won't do because the compiled JS is a separate project (you don't want errors because of duplicate definitions) and you need a jsconfig to get rid of certain errors (since not every option is supported by js/ts.implicitProjectConfig). Requiring jsconfig in a sub-folder is terrible because it won't work for all cases, so you'd have to mess with the user's desired folder structure.
Honestly, it should really just allow them in parallel.

If possible, ideally, it could even go as far as allowing e.g.:
tsconfig.json + jsconfig.json + Proj.tsconfig.json + Other Proj.tsconfig.json + Other Proj.jsconfig.json
Then users have full flexibility. If you have to disallow using the same file in multiple projects, then raise errors on the file. If not, just show "Multiple TS configs" in VSCode in this case.

[DanielRosenwasser]

Without necessarily addressing the current status of this issue, the workaround I'd suggest is to create both a tsconfig.ts.json and a tsconfig.js.json (or jsconfig.json if you really want), and a solution-style tsconfig.json that references them both.

// tsconfig.json
{
  // Include no files for a "solution-style" config.
  "files": [],

  "references": [
    { "path": "./tsconfig.ts.json" },
    { "path": "./tsconfig.js.json" },
  ]
}

[thislooksfun]

I 100% agree. I was just bit by this when trying to start adding ts into a legacy js project. Everything seemed to be going smoothly right up until I realized my intellisense and "jump to source" broke for the subpath imports in the .js files. The tsconfig file is tightly scoped to the new ts files (via "includes"), so the fact that the .js files no longer read from the "paths" defined in the jsconfig really caught me off-guard.

What I would expect to happen in that situation is that the tsconfig is applied first, and any remaining files not included by it fall back to the jsconfig. It seems that the current flow for a file f is:

if tsconfig exists:
  if tsconfig includes f:
    apply tsconfig
else:
  if jsconfig includes f:
    apply jsconfig

What I would find much more intuitive is

if tsconfig exists AND tsconfig includes f:
  apply tsconfig
else if jsconfig includes f:
  apply jsconfig

This way the tsconfig is always preferred, but the jsconfig is still respected on the files the tsconfig doesn't cover.