Suggestion: typescript module resolution support

[ValeryVS]

Update 1

app/
    shared/
        api-module/
        ui-module/
    heroes/
        heroes-list.component.ts

// tsconfig.json
{
  "compilerOptions": {
    "paths": {
      "#shared": [
        "app/shared"
      ]
    }
  }
}

// shared/index.ts
export * from './api-module/api.module';
export * from './api-module/api.service';
export * from './api-module/ui.module';
export * from './api-module/ui-notification.service';
export * from './api-module/ui-select.service';

// app/heroes/heroes-list.component.ts
import { Component } from '@angular/core';

import { ApiService } from '#api-module';
import {
    UINotyficationService,
    UISelectService
} from '#ui-module';

import { HeroesService } from './heroes.service.ts';

Original Post

TypeScript module resolution
microsoft/TypeScript#5039

Configs
Add baseUrl and, optionaly, paths to tsconfig.json

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "*": [ "modules/*" ]
    }
  }
}

Add modules to angular-cli.json apps

{
  "apps": [
    {
      "modules": [
        "src/modules"
      ]
  ]
}

Realisation
ValeryVS@c812fe8

Pros
Then we will be able to write
import { MyModule } from 'my';
and it will load module from src/modules/my/index.ts

We aslo can write src/app or src/app/shared to angular-cli.json and get rid of relative paths when we load services in app.

[kylecordes]

This also seems convenient to me from a syntax point of view. But I think there are some "cons" to go with the "pros" above - in particular around ease of understanding.

As developers first enter the typescript and Angular ecosystem, among 1000 other things they need to understand import statements. In the current default behavior, this can be explained in just a few seconds: import paths which start with "." are importing other modules in the application being worked on. Other imports (from paths that don't start with ".") are importing libraries, code written in other projects or by other people.

The typescript configuration described above would add more complexity to the current easy-to-understand default situation. So while I like it for my own convenience, I think this should be weighed as a trade-off before such a feature is put in to the default configuration CLI creates.

[ValeryVS]

I agree, that this feature can add mode complexity.
But we can provide minimal, but extendable, configuration.

Probably, the most frustrating is import {} from '../../../shared' (how many ../) while import shared service from complicated module.

Also, sometime we want to make shared module. With a few services. We can make it, as a separate package and import from node_modules. But it is simpler to leave it in main repository, if we don't need that module in other projects.

Wrap in.
I like the approach of #2210 with TsConfigPathsPlugin.
Main question is default configuration.

For example:

• relative import - start with "."
• node_modules import - no prefixes
• import from shared - suggest some prefix: # @ ^

Then, we be able to place shared modules into shared folder and import them with our prefix.

app/
    shared/
        api-module/
        ui-module/
    heroes/
        heroes-list.component.ts

// heroes-list.component.ts
import { Component } from '@angular/core';
import { HeroesService } from './heroes.service.ts';
import { ApiService } from '#api-module';
import {
    UINotyficationService,
    UISelectService
} from '#ui-module';

[ValeryVS]

First post updated.

Actually, new developer can simply use relative paths until he will encounter the tsconfig.json's path option.
All we need is support of this ability in standard webpack configuration.

[ValeryVS]

It seems I miss older similar issue #1465

[filipesilva]

Fixed by #2470

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}