Multiple Project Support

[basarat]

Note : Leaving this purely as a documentation, and potential idea for exploration by any TypeStrong / community member

How tsconfig.json detection works now.

We have a file/class called Project which basically consolidates all our access to the TypeScript language service (the code).

When you open a .tsx? file in the editor we lookup some tsconfig.json up the directory tree. If we find one we

• read it
• convert it to a project
• for all the files identified as a part of the project we create a hot cache so we share the same project for queries against these files.

(here is the code)

Issues with this

If you have several tsconfig.json files in your project, e.g.:

• server/tsconfig.json
• client/tsconfig.json

The tsconfig files also reference some shared files in:

• src/shared.

If you open a file from server first then all the files referenced (including shared) will point to that server/tsconfig.json. Then even if you update client/tsconfig.json it will have seemingly no effect on any file that the editor opens (as they all already point to server/tsconfig.json).

Potential fixes

Project selector

This is the approach I am taking with http://alm.tools/ . It features a project search/selector : https://github.com/alm-tools/alm/tree/master/docs/features#project-search + ability to provide a project on the command line (-p flag).

It is less magical then what atom-typescript does, but then again atom-typescript was designed to be as quick to start / unobtrusive as possible i.e. you open a ts file and it just works.

alm.tools is designed to be for typescript alone. You need a project file.

Multiple simultaneous projects

This is the approach taken by VSCode / TSServer (that comes with typescript out of the box).

However there are issues with this design too e.g.:

• autocomplete can end up with duplicates and deduplication needs to happen
• rename refactoring needs to take place across all the code base / projects.

All of these complex scenarios are being fixed in TSServer by the Microsoft team (:rose:) and if this is the approach that needs to happen I recommend that current code be pulled out and migrate to TSServer. This will result in feature decrease (e.g. dependency view) but might be better in the long term 🌹

Personal opinions

What I did with atom typescript isn't ideal for sure and it would be better if it takes one of the mentioned approaches. Please note that I did this before tsserver was a thing so ¯\_(ツ)_/¯, and because of (again) ambitious plans of https://alm.tools it does something custom (doesn't use tsserver again as I find my work on async support easier personally, also haven't had the time to take a hard look at TSServer) 🌹 ❤️

[psnider]

Here is a method I found that works for me
when I want to switch the atom-typescript project-focus to a new tsconfig.json:

• Select a file that is referenced by the filesGlob pattern in the tsconfig.json that you want to use.
  This file must be located within or below the directory that contains the tsconfig.json file.
  If the file path requires a relative reference ../
  then the tsconfig.json won't be found.
• Save the file, or run sync from within it ( ⌘ ' command+single-quote on mac)

[laurelnaiad]

I think about this subject from time to time.

My thoughts generally lead to a supposition that if atom-typescript's worker were based on the identification of a set of tsconfig files as its "drivers" (instead of having the editor window be the driver), that the process of identifying which project(s) include a given .ts (or now also .js) file would be more straightforward.

And, given that tsconfig files no longer need to be named tsconfig.json, it seems pretty obvious that somebody's now got to maintain or infer a list of them.

I know there's a lot more going on, because I've seen some of it and actually learned a bit of it, but I believe the process now is something like "I seem to be handling a ts file, let me findup for a tsconfig that includes this file", it would be, 'I seem to be handling a ts file, let me check my tsconfigs to see which projects (note the plural) include this file'.

Regarding the circumstance where more than one project includes the file, it seems to me that the only correct response is to process it under both regimes in parallel.

In psuedo code, I'm talking about:

errs: []
tsconfigs; WorkspaceTsConfigsList
with(.ts file) {
  tsconfigs.where(tsconfig.includes(file)).build(file)
  .onSuccess(report green)
  .onErr(err => errs.push(err))
}

and if I happen to have extra errors because my file is wrong in more than one project context, then I see the concatted errors, even if they all happen to be for the same reason...

What scares me in saying this is that I think it would be a lot of work to go in this direction...

[github-actions]

This issue has been marked as stale because it did not have any activity for the last 90 days or more. Remove the stale label or comment or this will be closed in 14 days