tsserver (vscode) does not recognize multiple tsconfig.json in the same directory

[tkrotoff]

Example of file organization:

app/feature1/model.ts
             model.spec.ts
             controller.ts
             controller.spec.ts
             template.html
             documentation.md
    feature2/model.ts
             model.spec.ts
             controller.ts
             controller.spec.ts
             template.html
             documentation.md
    tsconfig.json      <-- list *.ts files + third-party *.d.ts (ex: angular.d.ts)
    tsconfig.spec.json <-- list *.spec.ts files + third-party *.d.ts (ex: jasmine.d.ts)

tsc works fine. However vscode does not properly highlight files listed in tsconfig.spec.json (like #5828).

Using TypeScript 1.8.10 and vscode 1.0

[mhegazy]

This behaves as intended. there is only one special tsconfig.json. the other ones can be passed explicitly to tsc, but when automatic search is done, either in tsc or in tsserver, only tsconfig.json is looked up.

[tkrotoff]

Ok, so with tsserver

• you cannot have source code and tsconfig.json in separate directories (Different tsconfig lookup behaviour between tsc and tsserver #5828)
• you cannot have multiple tsconfig.*.json in the same directory (this issue)

then how can you organize code by features/components in a simple way? It is a valid use case.

TypeScript very first description line:

TypeScript is a language for application-scale JavaScript

[mhegazy]

then how can you organize code by features/components?

not sure i understand what you mean by this. if you have a tsconfig per feature/component it is going to work. what is not, is having multiple build configurations for the same feature/component in the IDE.

[tkrotoff]

Mohamed Hegazy (@mhegazy)

not sure i understand what you mean by this

by features/components/modules:

app/feature1/model.ts
             model.spec.ts
             controller.ts
             controller.spec.ts
             template.html
             style.css
             feature.png
             README.md
    feature2/model.ts
             model.spec.ts
             controller.ts
             controller.spec.ts
             template.html
             style.css
             feature.png
             README.md

vs by type of files:

src/models/feature1_model.ts
           feature2_model.ts
    controllers/feature1_controller.ts
                feature2_controller.ts
    templates/feature1_template.html
              feature2_template.html

doc/feature1.md
    feature2.md

styles/feature1.css
       feature2.css

img/feature1.png
    feature2.png

test/feature1_model.spec.ts
     feature2_model.spec.ts
     feature1_controller.spec.ts
     feature2_controller.spec.ts

Link from my previous comment: https://www.google.fr/search?q=organize+code+by+feature
Examples of AngularJS articles:

• https://medium.com/opinionated-angularjs/scalable-code-organization-in-angularjs-9f01b594bf06
• http://cliffmeyers.com/blog/2013/4/21/code-organization-angularjs-javascript
• https://coderwall.com/p/y0zkiw/building-large-apps-with-angularjs
• ...

Note: most articles don't mention where the tests should go because most people don't write tests and thus don't mention it.
Obviously you want your tests as close as possible to the code they test, not at the other side of your hard drive, same for your code documentation (you've recognized the 'by file type' organization here).
Writing tests and documentation is no fun, your code organization should not make it even harder else you can be sure your team won't never update the tests nor the documentation.

[mhegazy]

I still do not understand why you can not do this with one tsconfig.json per folder.

[tkrotoff]

why you can not do this with one tsconfig.json per folder

Nobody wants to ship something bundled with the tests on a website, so you need 2 tsconfig.json :)

Also having 1 build for the app and 1 build for the tests helps: you can easily experiment/hack with the app code without having compile errors about the now outdated tests. (typical workflow: hack -> looks good? -> clean things up + write tests).

Sure you can have 3 tsconfig.json instead of 2:

• one to please the IDE/tsserver
• one to build the app code
• one to build the tests

=> More things to maintain :/

[mhegazy]

Nobody wants to ship something bundled with the tests on a website, so you need 2 tsconfig.json :)

so why not two tsconfig.json files in two folders, i.e. src\tsconfig.json and test\tsconfig.json?

[tkrotoff]

src\tsconfig.json and test\tsconfig.json

Does not solve the problem, see #5828 (my first attempt before TypeScript 1.8 came out with the tsc -project fullpath feature).

I think allowing a tsconfig.json to reference other tsconfig.json (TypeScript 2.1) will simplify things:

• tsconfig.test.json => build the tests
• tsconfig.app.json => build the app
• tsconfig.json => pleases the IDE/tsserver, references tsconfig.test.json and tsconfig.app.json

You have 3 tsconfig.json files but the one for the IDE is just an empty shell that points to the others: easy to maintain.
It still feels awkward: go explain to somebody why you have 3 tsconfig.json files...

Another better (and complementary?) solution can be multiple "targets"/builds/projects inside 1 tsconfig.json file (see #1928):

{
  "compilerOptions": {
    "noImplicitAny": true,
    "removeComments": false,
    "sourceMap": true
  },
  "files": [
    "common/util.ts"
  ]
  "projects": {

    "app": {
      "compilerOptions": {
        "outFile": "app.js"
      },
      "files": [
        "feature1/model.ts",
        "feature1/controller.ts",
        "feature2/model.ts",
        "feature2/controller.ts"
      ]
    },

    "unittests": {
      "compilerOptions": {
        "outFile": "unittests.js"
      },
      "files": [
        "feature1/model.spec.ts",
        "feature1/controller.spec.ts",
        "feature2/model.spec.ts",
        "feature2/controller.spec.ts"
      ]
    },

    "e2etests": {
      "compilerOptions": {
        "outFile": "e2etests.js"
      },
      "files": [
        "feature1/e2e.spec.ts",
        "feature2/e2e.spec.ts"
      ]
    },

    "app-es3-amd": {
      "compilerOptions": {
        "target": "es3",
        "module": "amd",
        "outFile": "app-es3-amd.js"
      },
      "files": [
        "feature1/model.ts",
        "feature1/controller.ts",
        "feature2/model.ts",
        "feature2/controller.ts"
      ]
    }
  }
}

• Only one tsconfig.json file \o/
• IDE/tsserver always happy \o/
• Easy to understand and scalable
• Pass the target name to tsc otherwise all targets are compiled (default behavior)

[mhegazy]

This is not the intended use of tsconfig.json. it is not meant to be a build orchestration tool nor a solution file. a single tsconfig.json represents a single invocation to tsc.exe/tsc.js. and that is that. for more interesting build/configuration consider using other build tools e.g. MSBuild, grunt or gulp.

my recommendations for this scenario are:

• use two tsconfig.json files, one in sources and one in tests.
• use a build tool to ensure building the tests will build the sources, e.g. grunt/gulp
• in your editor, once you open a file from the test directory and a file from the source directory, two projects will be loaded in memory, with Enable tsserver global operations to be performed on all projects #7353, you get the global operations like find all references, and rename working on both projects. and no need for an uber project that unify them.

[tkrotoff]

consider using other build tools e.g. MSBuild, grunt or gulp [...] use a build tool to ensure building the tests will build the sources

Obviously, how can you do without? sass/less, minification, launch a server, move files around, call tsc -p...

use two tsconfig.json files, one in sources and one in tests.

Does not please the IDE, see #5828. You can check for yourself: https://github.com/tkrotoff/vscode-tsconfig.conf-issue

Anyway...

[basarat]

use two tsconfig.json files, one in sources and one in tests.

This is the one I'd recommend as well. The test file should be in a folder above the src. TSServer will work as it is

Project pitch

I'll work on improving the set project in alm to take more than files by tsconfig.json name at some point so it shows more than just tsconfig.json exact matches https://github.com/alm-tools/alm/blob/master/docs/features/omni-search.md#project-search
🌹