35

I use project references to reference "shared" project from "front" and "back" ones.

tsc -v: Version 3.3.3

Project structure:

./{MY_PROJECT}.code-workspace   /* the only file in this level */
./back
./back/tsconfig.json
./shared/src/
./shared/
./shared/tsconfig.json
./shared/src/
./front
./front/tsconfig.json
./front/src

I am tring to import a module to ./front/src/article-view-model.ts from the shared project:

import Article from "@shared/src/article";            // alias path
import Article from "../../shared/src/article"; // full relative path
export default class ArticleViewModel {
}

The following errors are shown immediately in VS Code GUI:

For alias path:

Cannot find module '@shared/src/article'. ts(2307)

For full relative path:

Output file '../../shared/src/article' has not been built from source file 'c:/{SOMEWHERE_IN_MY_PC}/shared/src/article.ts'. ts(6305)

Intellisense (VS Code) does work for both alias and relative options:

Intellisense

If i try ignore the errors and build, it fails with that:

C:\Program Files\nodejs\node_modules\npm\bin\node_modules\typescript\lib\tsc.js:1296 throw e; ^

Error: Debug Failure. False expression. at mergeSymbol (C:\Program Files\nodejs\node_modules\npm\bin\node_modules\typescript\lib\tsc.js:25861:26) at C:\Program Files\nodejs\node_modules\npm\bin\node_modules\typescript\lib\tsc.js:25960:47 at Map.forEach () at mergeSymbolTable (C:\Program Files\nodejs\node_modules\npm\bin\node_modules\typescript\lib\tsc.js:25958:20) at initializeTypeChecker (C:\Program Files\nodejs\node_modules\npm\bin\node_modules\typescript\lib\tsc.js:48653:21) at Object.createTypeChecker (C:\Program Files\nodejs\node_modules\npm\bin\node_modules\typescript\lib\tsc.js:25711:9) at getDiagnosticsProducingTypeChecker (C:\Program Files\nodejs\node_modules\npm\bin\node_modules\typescript\lib\tsc.js:71398:93) at Object.getGlobalDiagnostics (C:\Program Files\nodejs\node_modules\npm\bin\node_modules\typescript\lib\tsc.js:71755:72) at Object.getGlobalDiagnostics (C:\Program Files\nodejs\node_modules\npm\bin\node_modules\typescript\lib\tsc.js:73528:86) at buildSingleProject (C:\Program Files\nodejs\node_modules\npm\bin\node_modules\typescript\lib\tsc.js:75803:127)

./front/tsconfig.json contents:

{
    "compilerOptions": {
        "allowSyntheticDefaultImports": true,
        "baseUrl": ".",
        "module": "amd",
        "noEmitOnError": true,
        "noImplicitAny": false,
        "out": "./lib/front-bundle.js",
        "paths": {"@shared/*" : ["../shared/*"]},
        "preserveConstEnums": true,
        "removeComments": true,
        "sourceMap": true,
        "target": "es2015",
        "watch": true
    },
    "include": [
        "./src/**/*.ts",
    ],
    "references": [
        {
            "path": "../shared"
        }
    ]
}

./shared/tsconfig.json contents:

{
    "compilerOptions": {
        "allowSyntheticDefaultImports": true,
        "composite": true,
        "declaration": true,
        "module": "amd",
        "noEmitOnError": true,
        "noImplicitAny": false,
        "out": "./lib/shared-bundle.js",
        "preserveConstEnums": true,
        "removeComments": true,
        "sourceMap": true,
        "target": "es2015",
        "watch": true
    },
    "include": [
        "./src/**/*.ts",
    ]
}
Dorad
  • 3,413
  • 2
  • 44
  • 71

7 Answers7

40

Found this when searching for "typescript references has not been built from source file". My mistake was that I was running tsc -p tsconfig.json when I should've been using the --build flag: tsc --build tsconfig.json. If you run with -p TypeScript will not build the referenced projects. Only if you run with --build.

Sebastian
  • 3,322
  • 22
  • 34
7

I arrived here trying to solve a "has not been built from source file" error. Turned out a tsc watch process hadn't properly exited, so I had two instances fighting over the files. Just in case anyone else runs into the same issue

JaffaTheCake
  • 13,895
  • 4
  • 51
  • 54
6

I solved it little after my last activity here, but i wasn't 100% sure if that happened due to the following changes. I am posting it here anyway, as there are still new views and votes, so it may be valuable for others:

That was the change:

In ./shared/tsconfig.json contents

I added

{
   "outDir": "./lib/",
   ...
   "rootDir": "./src",
}

to give:

{
    "compilerOptions": {
        "allowSyntheticDefaultImports": true,
        "composite": true,
        "declaration": true,
        "module": "amd",
        "noEmitOnError": true,
        "noImplicitAny": false,
        "outDir": "./lib/", <-------------
        "preserveConstEnums": true,
        "removeComments": true,
        "rootDir": "./src", <-------------
        "sourceMap": true,
        "target": "es2015",
        "watch": true
    },
    "include": [
        "./src/**/*.ts",
    ]
}
Liam
  • 27,717
  • 28
  • 128
  • 190
Dorad
  • 3,413
  • 2
  • 44
  • 71
3

I'm able to reproduce the errors you get if I have an errant tsconfig.json in the directory that contains front, back and shared. In this case running tsc -b will pick up the errant tsconfig.json in the current directory and since it is not configured with the right paths or anything else, the compilation fails with the same errors you get.

Otherwise, if I use your files and issue tsc -b front instead of tsc -b, it compiles without error.

The reason VSCode does not run into trouble is that in order to provide completion, TypeScript editors (normally) use a tool provided by TypeScript called tsserver. And when an editor gives a file path to tsserver, tsserver gets a relevant tsconfig.json by looking in the directory that contains the source file, and then up into the parent directory, and so on, until it finds a tsconfig.json file. So when VSCode works on front/src/foo.ts and asks tsserver to provide completion, tsserver looks in front/src which has no matching file, and then front, and finds the tsconfig.json there.

Louis
  • 146,715
  • 28
  • 274
  • 320
2

If you are compiling from root folder, try to add a local tsconfig.json file with all references set up, i.e. references: { path: './shared' }. Otherwise, tsc will not find relevant project to build.

Furthermore not having a root tsconfig.json will not allow VSCode GUI to work properly as it looks for root tsconfig.json (this is the state last time I checked it, here you can find the related issue).

The error seems to be related to missing file. If you can provide further details about the building steps you take, I can try to check it better

leonardfactory
  • 3,353
  • 1
  • 18
  • 25
0

This totally doesn't answer your question directly, but I feel it might still be useful to offer an alternative.

One way to solve this in a 'more standard' fashion, would be to make your 3 codebases all an NPM package.

This way your import would be something like @vendor/shared/foo instead of ../../../../shared/src/article.

Using npm link it's easy to work on a project cross-dependency.

You don't technically even need to modify your source structure (although maybe you want to). The shared dependency just gets softlinked via node_modules.

Evert
  • 93,428
  • 18
  • 118
  • 189
  • 5
    As an advice, I should say that using `npm link` is not always the best way to go. I've found some issue since *symbolic links* are used, and so dependencies cannot be flattened, leading to differences between final build and development. It's a cool tool sure for development, but not always the best solution. Just my two cents! – leonardfactory Mar 15 '19 at 15:02
  • @leonardfactory that's good to know! Usually having 'npm link' on is a temporary state for me until I can stop doing cross-repo development. I can definitely see that that can become an issue. – Evert Mar 15 '19 at 19:44
  • I try to use yalc for local development, It works like npm link, has flattening support and a nice watch mode, I suggest it! – leonardfactory Mar 15 '19 at 19:47
  • @leonardfactory - "... symbolic links are used, and so dependencies cannot be flattened" needs a little more explanation to make sense. Symbolic links enable dependencies to be flattened - that's the whole point. There is one caveat - at least for yarn - links for bin executables are not created during "yarn install [--offline] [--force]" unless the path in package.json::"bin{name:path}" actually exists. To get around that "yarn install [--offline] [--force]" must be called again after compilation has completed successfully, before the executables are called. – Craig Hicks Mar 31 '22 at 19:57
  • This answer is vastly underrated. – Craig Hicks Mar 31 '22 at 20:04
0

It seems that this error can be caused by many things. For me the problem was that I deleted the output directory in the shared project without deleting the tsconfig.tsbuildinfo file. It seems that this file is some sort of cache to prevent referencing projects from rebuilding the shared project.

Ameen
  • 1,747
  • 3
  • 16
  • 31