angular-cli: tsconfig "paths" config is not recognized

Mac OSX Sierra angular-cli version 1.0.0-beta.24

I’m trying to configure things so I don’t have to use ugly (and brittle) relative paths when including modules from my own project. I modified tsconfig.json to include:

  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@app/*": "app/*"
    },
   ...

And that works great for TypeScript.

However, “ng serve” is throwing this error:

ERROR in ./src/app/content/content.component.ts
Module build failed: Error: /Users/lehresman/Projects/gazelle-ui/src/app/content/content.component.ts (2,29): Cannot find module '@app/models/client.model'.)
    at _checkDiagnostics (/Users/lehresman/Projects/gazelle-ui/node_modules/@ngtools/webpack/src/loader.js:116:15)
    at /Users/lehresman/Projects/gazelle-ui/node_modules/@ngtools/webpack/src/loader.js:141:17
 @ ./src/app/app.module.ts 17:0-65
 @ ./src/main.ts
 @ multi main

I’ve discovered that Webpack has configuration options for this, but I can’t figure out how to configure Webpack through Angular-CLI to support this. Is this a bug, or is this feature not exposed?

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Reactions: 1
  • Comments: 48 (7 by maintainers)

Most upvoted comments

I seems like the error was that tsconfig.app.json was overwriting the baseUrl option of the root-level tsconfig.json, setting it to ./ (instead of just .). Once I removed that option from that file, the build was successful.

Also, for posterity, I had to make the paths be an array. It looks like Typescript accepts a string, but angular-cli expects it to be an array.

  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@app/*": ["app/*"]  // <-- must be an array
    },
   ...

I have the same problem as @ivanguimam mentioned, has anyone solved this? My app works fine but my e2e tests crashing every time when I try to start them with path variables.

is this broken for anybody in Angular 7? I don’t see paths anymore in https://angular.io/api/core/CompilerOptions I’m getting compilation errors with ng serve on all of the paths that I had in tsconfig.json

@duncanwerner I used your idea and got it to work on Mac. Seems like the builder uses tsconfig.app and linter(?) uses tsconfig

tsconfig:

{
  "compileOnSave": false,
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "*": [
        "*",
        "src/app/*",
        "src/environments/*"
      ]
    },
    "outDir": "./dist/out-tsc",
    "sourceMap": true,
    "declaration": false,
    "moduleResolution": "node",
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "target": "es5",
    "typeRoots": [
      "node_modules/@types"
    ],
    "lib": [
      "es2017",
      "dom"
    ]
  }
}

tsconfig.app

{
  "extends": "../tsconfig.json",
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "*": [
        "*",
        "app/*",
        "environments/*"
      ]
    },
    "outDir": "../out-tsc/app",
    "module": "es2015",
    "types": []
  },
  "exclude": [
    "test.ts",
    "**/*.spec.ts"
  ]
}

Solved the problem in Angular 7 adding the paths to both tsconfig files

  • paths in tsconfig.json helps vscode to works and with intellisense
  • paths in tsconfig.app.json is also needed for angular

tsconfig.json

image

tsconfig.app.json

image

and the intellisense works great

image

I have a problem similar to this when I run the tests E2E

Angular CLI version:

Angular CLI: 1.7.3
Node: 8.9.1
OS: linux x64
Angular: 5.2.9
... animations, common, compiler, compiler-cli, core, forms
... http, language-service, platform-browser
... platform-browser-dynamic, router

@angular/cli: 1.7.3
@angular-devkit/build-optimizer: 0.3.2
@angular-devkit/core: 0.3.2
@angular-devkit/schematics: 0.3.2
@ngtools/json-schema: 1.2.0
@ngtools/webpack: 1.10.2
@schematics/angular: 0.3.2
@schematics/package-update: 0.3.2
typescript: 2.7.2
webpack: 3.11.0

tsconfig.json

{
    "compileOnSave": false,
    "compilerOptions": {
        "outDir": "./dist/out-tsc",
        "sourceMap": true,
        "declaration": false,
        "moduleResolution": "node",
        "emitDecoratorMetadata": true,
        "experimentalDecorators": true,
        "target": "es5",
        "typeRoots": [
            "node_modules/@types"
        ],
        "baseUrl": ".",
        "paths": {
            "@service/*": ["src/app/shared/service/*"],
            "@directive/*": ["src/app/shared/directive/*"],
            "@component/*": ["src/app/shared/component/*"],
            "@entity/*": ["src/app/entity/*"],
            "@enum/*": ["src/app/enum/*"],
            "@environment/*": ["src/environments/*"],
            "@shared/*": ["src/app/shared/*"],
            "@guest/*": ["src/app/guest/*"],
            "@dashboard/*": ["src/app/dashboard/*"],
            "@validator/*": ["src/app/validator/*"],
            "@interface/*": ["src/app/interface/*"],
            "@mask/*": ["src/app/mask/*"],
            "@pipe/*": ["src/app/shared/pipe/*"],
            "@e2e/*": ["e2e/*"],
            "@factory/*": ["factory/*"],
            "@mock/*": ["mock/*"],
            "@database/*": ["database/*"]
        },
        "lib": [
            "es2017",
            "dom"
        ]
    }
}

tsconfig.e2e.json

{
    "extends": "../tsconfig.json",
    "compilerOptions": {
        "outDir": "../out-tsc/e2e",
        "module": "commonJS",
        "types": [
            "jasmine",
            "jasminewd2",
            "node"
        ]
    }
}

Error: Error: Error: Cannot find module '@e2e/utils/utils'

vscode (or presumably any other editor, but that’s what I use as well) uses the root tsconfig.json. so make sure that aliases in that file are correct relative to the location of that file. you may also have to close/open files or even the whole editor to get it to refresh the cache.

I believe this regressed. I had the following setup in [root]/tsconfig.json:

{
    ...
    "baseUrl": "src",
    "paths": {
      "@local/*": ["../local_modules/*"]
    }
    ...
}

and then in my files I referenced packages in local_modules using the @local/X alias. That worked in 1.2.3. I just upgraded to 1.3.0, and it fails. Reverting to 1.2.3 resolves it. I’m not sure if this was supposed to work, or if this was just a hack I found in the comments.

I am having trouble getting paths to work when building packages. ie in the tsconfig.lib.json I have added:

"paths": {"@lib/*": ["lib/*"], },

to tsconfig.lib.json and then try to utilise it with a path such as

import { CrossfilterDataComponent } from "@lib/bids/crossfilter-data/crossfilter-data.component";

the target file is src/lib/bids/crossfilter-data/crossfilter-data.component.ts

@Bengreen I have the same problem. Did you find the solution?

that does work great since your mapping directly to individual files, but may still fail when using the * wildcard. After reading the Module Resolution page, I ran tsc --traceResolution

'baseUrl' option is set to 'C:/Users/WindowsUsers/source/repos/path-alias-test/src', using this value to resolve non-relative module name '@services'.
'paths' option is specified, looking for a pattern to match module name '@services'.
Module name '@services', matched pattern '@services'.
Trying substitution 'app/services/*', candidate module location: 'app/services/*'.
Loading module as file / folder, candidate module location 'C:/Users/WindowsUsers/source/repos/path-alias-test/src/app/services/*', target file type 'JavaScript'.
File 'C:/Users/WindowsUsers/source/repos/path-alias-test/src/app/services/*.js' does not exist.
File 'C:/Users/WindowsUsers/source/repos/path-alias-test/src/app/services/*.jsx' does not exist.
Directory 'C:/Users/WindowsUsers/source/repos/path-alias-test/src/app/services/*' does not exist, skipping all lookups in it.
Loading module '@services' from 'node_modules' folder, target file type 'JavaScript'.
Directory 'C:/Users/WindowsUsers/source/repos/path-alias-test/src/app/node_modules' does not exist, skipping all lookups in it.
Directory 'C:/Users/WindowsUsers/source/repos/path-alias-test/src/node_modules' does not exist, skipping all lookups in it.
File 'C:/Users/WindowsUsers/source/repos/path-alias-test/node_modules/@services.js' does not exist.
File 'C:/Users/WindowsUsers/source/repos/path-alias-test/node_modules/@services.jsx' does not exist.
Directory 'C:/Users/WindowsUsers/source/repos/node_modules' does not exist, skipping all lookups in it.
Directory 'C:/Users/WindowsUsers/source/node_modules' does not exist, skipping all lookups in it.
Directory 'C:/Users/WindowsUsers/node_modules' does not exist, skipping all lookups in it.
Directory 'C:/Users/node_modules' does not exist, skipping all lookups in it.
Directory 'C:/node_modules' does not exist, skipping all lookups in it.
======== Module name '@services' was not resolved. ========

I was able to fix it finally by setting my tsconfig (tsconfig.app.json has no baseUrl or Paths because it only extends tsconfig)

 "baseUrl": "src",
  "paths":{
      "@services":["app/services/"]
   },

and appropriately using index.ts files just like node_modules/@angular does. The * were the culprit.

I still haven’t figured this out completely, but I have a workaround. This may be a windows-specific problem. This does not work:

    "baseUrl": ".",
    "paths": {
      "@local/*": [
        "../local_modules/*"
      ]
    }

This does work (baseURL moves up one directory, paths moves down):

    "baseUrl": "..",
    "paths": {
      "@local/*": [
        "local_modules/*"
      ]
    }

Hope that helps someone. I may try to track down the specific problem, but it’s not a typescript problem; trying a generic tsc compile with a different config, both of these work.

In my case tsconfig.spec.json was overwriting baseUrl

Yeah, I mean the error was that I wasn’t aware of the overwriting, not that “the file is overwriting my config, that’s an error, how dare that file!”.

Now I just found a little thing. The IDE (vscode) doesn’t show any suggestions while I type a path using the alias (so it won’t autocomplete, I have to write the full path). Is there a way to fix this? Not that it’s too important but… if it can be fixed it’d be nice.

image

I commented out baseUrl property in tsconfig.app.json and now everything works including intellisense and ng serve. Previously intellisense worked but ng serve failed with “Cannot find module” errors.

tsconfig.json:

"baseUrl": "./",
"paths": {
  "@services/*": ["src/app/components/services/*"],
  ...
}

tsconfig.app.json relevant config

"compilerOptions": {
  "outDir": "../out-tsc/app",
  //"baseUrl": "./",
  "module": "es2015",
  "types": ["highcharts"]
},

I think I’ve got it fixed now

Setup

  • ng new path-alias-test
  • cd path-alias-test
  • npm i -g npm-check-updates && ncu -a && npm i (upgrades all packages to latest)
  • ng g s services/a
  • ng g s services/b
  • ng g s services/sub/c
  • in tsconfig.json compilerOptions node
"baseUrl": "src",
"paths":{
   "@services/*":["app/services/*"]
},
  • in app.component.ts
import { AService } from '@services/a.service';
import { BService } from '@services/b.service';
import { CService } from '@services/sub/c.service';
...
export class AppComponent {
  title = 'app';
  a: AService;
  b: BService;
  c: CService;
}

  • ng serve

The above compiles fine with no errors.

When we add barrel files in order to simplify our imports

src/app/service/index.ts

export * from './sub';
export * from './a.service';
export * from './b.service';

src/app/service/sub/index.ts

export * from './c.service';

and change app.component.ts imports to

import { AService, BService } from '@services/';
import { CService } from '@services/sub';
  • ng serve gives us ERROR in src/app/app.component.ts(2,36): error TS2307: Cannot find module ‘@services/’. Why are we getting this error now?

Resolution

If we remove the final * in tsconfig.json paths

"paths":{
   "@services/*":["app/services/"]
},
  • ng serve now compiles fine with no errors. I’m not sure why we had to change ["app/services/*"] to ["app/services/"] for concise imports to work with barrel(index.ts) files.

I am having trouble getting paths to work when building packages. ie in the tsconfig.lib.json I have added:

"paths": {"@lib/*": ["lib/*"], },

to tsconfig.lib.json and then try to utilise it with a path such as

import { CrossfilterDataComponent } from "@lib/bids/crossfilter-data/crossfilter-data.component";

the target file is src/lib/bids/crossfilter-data/crossfilter-data.component.ts

Sorry, I misunderstood. It does not autocomplete aliased paths. File a feature request over at the vscode repo.

Maybe related to #7341, although for me --aot does not work either.

Thanks for letting me know that it was supported. I was chasing rabbit trails trying to get angular-cli to support it, but turns out it IS supported already. I simply had my paths wrong.