Add project source dir as a module

[filipesilva]

It would be very useful to be able to address components via a relative path starting at the project root. A way to do this is to consider the project root as a special project, as if it was inside of node_modules as far as resolution is concerned.

Such a design greatly reinforces the 'app as a library' idea, and plays nice with most module loading scheme.

A proposed name is @app but configurable via angular-cli.json, where app is the project prefix specified in ng new --prefix app (this exists already and defaults to app).

Example:

// instead of 
import { something } from '../../../../../../../shared/something';
// we could do
import { something } from '@app/shared/something';

This would also work for CSS preprocessors.

Such implementation would address #865 and also greatly reduce the need for #900.

[sirajc]

Have seen similar thing in ng-bootstrap. The demo project inside refers to the main project using @ng-bootstrap and it is using webpack

[TheLarkInn]

In terms of webpack implementation would we be taking this @app property and mapping them to the webpack alias for module resolution @filipesilva

[filipesilva]

Something important that came up: editor tooling would never be able to find @app. You'd always have errors on your editor.

[clydin]

There are also tsconfig's baseUrl and paths options. This would only apply to typescript files but allows editors (e.g., vscode) to process and follow the mapping.

To make the current version of vscode pick up the settings, you'll need to add a workspace settings file with "typescript.tsdk": "./node_modules/typescript/lib" (make sure it points to your actual typescript location).

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

UPDATE:

The above additions to tsconfig and the inclusion of the TsConfigPathsPlugin in the CLI's web pack config work well so far. It definitely simplifies and improves readability of typescript imports.

[masaanli]

Can't wait on this one :) Also struggling with FontAwesome Fonts implementation. Did a CDN for now...

[chapati23]

Another thing to be aware of with aliases is tests. Just because webpack knows @app as an Ali's doesn't mean mocha or karma etc. will know how to resolve it

I've tried this, the TypeScript compiles, but I get bundle errors from webpack. I.e. I've added this to tsconfig.json:

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

but e.g.

import { CommonModule} from '@app/common';

throws the error:

Module not found: Error: Can't resolve '@app/common' in 'src\client\src\app'
 @ ./src/app/client.module.ts 17:0-68 26:0-43
 @ ./src/main.ts
 @ multi main

I feel like I have to update webpack configuration somewhere?

@clydin

The above additions to tsconfig and the inclusion of the TsConfigPathsPlugin in the CLI's web pack config work well so far. It definitely simplifies and improves readability of typescript imports.

@clydin How did you include TsConfigPathsPlugin, as the webpack configuration is blackboxed? And I had a look, and it's not in there?

[ggranum]

I have basically @rolandoldengarm's issue, but there's a case that might be worth testing for someone: npm link.

When I attempted anything using symbolic links it seemed that webpack would resolve the real path instead of the alias. Combined with 'tsconfig:paths' not working yet, I cannot fathom solution to 'develop using modules' that's supportable long term.

Mostly want to call this out because at the moment this is listed as 'nice to have', and I really can't imagine being able to use the tool in this state long term.

I tried npm link, obviously. But also a few direct symbolic links - the craziest failure was when I symbolically linked a module that depends on another. Consider B depends on A: With both A and B npm install'd, everything works fine. However, removing the install of B and instead creating a symbolic link so that it looks like the source is under the 'app' directory, (and modifying the app.module.ts accordingly) fails, because it can't find module A.

On the chance this might be of interest to someone here I added some scripts to my repos to help demo it. If not interested, no worries.

The repositories I'm working on are https://github.com/ggranum/revector and https://github.com/ggranum/revector-demo

Specifically, if you clone both of those into the same parent and run

npm install
ng serve

Everything should work. Now stop the server and run:

 ./symlink-email-module.sh 
ng serve

and you should reproduce the errors I'm seeing [though note that the sed command in the bash scripts may break on non-macs] :

ERROR in ../revector/src/lib/email-password-top-nav-login/top-nav-login.component.ts
Module not found: Error: Can't resolve '@revector/auth-service' in '/Users/ggranum/github/ggranum/revector/src/lib/email-password-top-nav-login'
 @ ../revector/src/lib/email-password-top-nav-login/top-nav-login.component.ts 12:0-68
 @ ../revector/src/lib/email-password-top-nav-login/email-password-top-nav-login.module.ts
 @ ../revector/src/lib/email-password-top-nav-login/index.ts
 @ ./src/app/app.module.ts
 @ ./src/app/index.ts
 @ ./src/main.ts
 @ multi main

There's a bash script to create npm links as well (but run the uninstall-revector.sh script first).

If nothing else, hopefully this post serves to point out how hard it will be to write modular code in external projects without this feature.

Thanks much

We're using symlink (Windows) and it's working fine with system-config. Have not tested npm link yet.

And I agree priority should be increased. Previously our code was quite a mess with all the ../../../.. and ../../.., etc., and requiring changing all the imports when moving stuff around.
Now it is super clean with "import {..} from 'app/domain"

[ggranum]

@rolandoldengarm I am now deeply curious: what do you mean when you referenced system-config? Are you using system-config in combination with the webpack version of the CLI? If so, I'd love to hear more...

As for symlinks... this is unquestionably a design failure of Node. I have a few horrible, evil ideas about how to make the ' --preserve-symlinks' flag propagate through Node's call chain, but nothing I'd be proud of. And certainly nothing that would 'just work' when I clone my repository onto another machine, for example. It might be possible that there is something relatively simple the CLI team could do to enable symlink'd directories to work properly with node/webpack... but a) I doubt it and b) why bother? Leveraging tsconfig:paths just makes so much more sense.