[Feature] Structuring apps like angular-cli is structured itself

[about-code]

Bug Report or Feature Request (mark with an x)

- [ ] bug report -> please search issues before submitting
- [X] feature request

Versions

@angular/cli 1.0.0

Desired functionality

I would like to be able to structure an angular application in a way similar to how the angular and angular-cli repositories are structured, that is, having a project folder with a src directory (same as packages in the angular repos) wherein any folders make a valid NPM package (or package scope). The TypeScript-Transpiler should include src in its module resolution process and Webpack should include the folder where the Transpiler output is written to in its module resolution process.

For example instead of being tied to a structure src/app/... I would like to be able to have a project structure

+-/src
|   +- /@foo
|        +- /my-foo-app
|        |     |- src
|        |     |     |- AppComponent.ts
|        |     |     |- AppModule.ts
|        |     |     | ...
|        |     |- package.json     // feature package
|        |     |- index.ts
|        |     |- ...
|        +- /my-foo-feature
|              |- src
|              |- package.json     // feature package
|              |- index.ts
|
|- package.json     // project package
|- tsconfig-aot.json
|- tsconnfig.json
|- ...

Why such a structure?

Given two features @foo/my-foo-app and @foo/my-foo-feature I would like @foo/my-foo-app to be able to import classes from @foo/my-foo-feature as if it were a normal (or scoped) NPM package, for example I would like to use an absolute path / a module name in ES2015 import statements:

// src/@foo/my-foo-app/src/AppModule.ts
import {FooFeatureModule, FooClass} from "@foo/my-foo-feature".

For this to work TypeScript can be configured with the baseUrl compiler option by which we can tell TypeScript module resolution to look for modules inside of /src/. However, currently I am stuck with the CLI because Webpack would also need to be configured such that it looks up modules from where the transpile step wrote the JS-files to. Lets assume they were written to /target/@foo/..., then with Webpack's resolve.modules option pointing to target (see article here) it should be possible to make Webpack resolve above import statement.

Unfortunately the CLI itself tries to pretty much cover up Webpack configuration so I can not customize Webpack here. Further the CLI forces me to generate stuff into src/app.

Since this feature request is actually very much about being able to organising applications in a way like the whole angular framework sources are structured already today, I think you (angular-devs) should already be familiar with the benefits of your structure. From an enterprise and big-app development perspective I see the following benefits:

Benefits

• By structuring applications according to NPM package best-practices, it becomes a lot easier to really modularize an app (that is, beyond @NgModule). For example if @foo/my-foo-feature above turned out to be useful to another app, the feature could be just pulled out of the application source tree into its own distinct (library) project and then published to an NPM registry. The changes to the application which formerly held the sources of that package are minimal - basically its just adding the pulled-out feature package to the project's package.json and installing the package with npm install again. The original application doesn't care where the sources of @foo/my-foo-feature are (whether in src or in node_modules). It just continues to consume it like an ordinary npm package. The key enabler to this flexibility, however is, that my-feature-app is able to import the API of @foo/my-foo-feature by a path resembling that feature's NPM package name. As outlined above this needs special configuration for the Transpiler and the Bundler.

• By facilitating NPM package structures inside src any exports of a feature (the public API) are to be declared by an index.ts (package facade). People are encouraged to provide such an index.ts which makes features themeselves depend less on other features internal folder structures and file names.

• By facilitating NPM package structures people are encouraged to think in packages and their dependencies which is a key aspect in good software design (IMHO).

Are there any plans in making "package-style" ES2015 imports like exemplified above, possible for Angular apps created using the CLI?

Caveats

Managing dependencies when there are a lot feature packages can introduce a certain maintance overhead. As long as feature packages aren't published to an NPM registry, their (external) NPM dependencies may best be declared in the project package's package.json, only.

[filipesilva]

I agree that there are many benefit to a mono-repo approach, and this is a structure we want to support when we add library support (#1692).

We have multiple app support at the moment (#5737) but without supporting libraries it's hard to really have a practical mono-repo with cross dependencies.

[about-code]

Closing this in favour of #1692.

[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.}