Generate standalone library project

[epelc]

Are there any plans to support generating a standalone single library project without generating a app? Right now you use ng new to create a new app and then add a library with ng g library. Are there any plans to add a --lib option to ng new if you wish to have a standalone git project?

I know there are numerous workarounds such as just ignoring the empty app or sticking your shared lib in some app project but this would be useful.

edit: so I just found out ng new really generates a workspace + a default project outside the proejcts dir. Maybe the solution is just not generate the default project and make a lib instead if the rest of the cli thinks of things in terms of workspaces.

[epelc]

Manual way to remove the default project

1. rm -r src && rm -r e2e
2. Remove projectName and projectName-e2e keys from angular.json under projects key.
3. Remove the defaultProject key from angular.json
4. Remove all the dependencies from package.json(the required ones will be re-added once you generate your first library)
5. Generate a library ng g library mylibname
6. Build and publish ng buid mylibname && cd dist/mylibname && npm publish

[filipesilva]

There isn't a flag to do this on ng new but it is something we have discussed. I'd like to point out that usually one would want to test their libraries on a real app while developing though.

[Wykks]

For me, the use case is just about having a way to ng new where everything is in project dir. Default app (if there is one) outside project, is not very clear when browsing the code.

[epelc]

@Wykks I'm also for that. Having special dirs outside projects seems counterintuitive once you start using the cli for more.

[jlmonteagudo]

I also think that it would be more clear if the default project was inside the projects folder.

[SirMaxxx]

I think it is better to keep the default project outside the projects directory - it is then ideal for knocking up tests for any packages built in the projects directory without having to create some sort of 'myTestPackageProject' to do so.
the /projects directory is for 'real' projects - everything outside can be treated as part of the dev environment.

For exmaple, my deployment could build all projects in /projects - without having to decide which are just handlers for testing my libraries.

[filipesilva]

Related to #11402

[sergiojoker11]

Manual way to remove the default project

1. rm -r src && rm -r e2e
2. Remove projectName and projectName-e2e keys from angular.json under projects key.
3. Remove the defaultProject key from angular.json
4. Remove all the dependencies from package.json(the required ones will be re-added once you generate your first library)
5. Generate a library ng g library mylibname
6. Build and publish ng buid mylibname && cd dist/mylibname && npm publish

Step number 4 is not accurate - well, it is not with the versions specified below. It doesn't install the required dependencies when the library is created.
First of all, the package.json should not be updated manually. It would be fine this time to remove the dependencies manually and then remove the node_modules folder and the package-lock.json and finally npm install so that npm creates a consistent package-lock.json and install all the dependencies.
Secondly, if you remove all the dependencies from the main project then it moans about "rxjs" and "angular/core" first, then "@angular/compiler".
Therefore, in order to be able to build this library some dependencies need to be added to the project (main package.json) i.e. the ones indicated above.
But what it is crucial for it, it is to keep these devDependencies:

   "@angular-devkit/build-angular": "~0.8.0",
    "@angular-devkit/build-ng-packagr": "~0.8.0",
    "@angular/compiler-cli": "^6.1.0",
    "ng-packagr": "^4.1.0",
    "tsickle": ">=0.29.0",
    "tslib": "^1.9.0",
    "typescript": "~2.9.2"

These are the dependencies I have:

   "@angular/animations": "^6.1.10", //Optional -> Relative to my project
    "@angular/common": "^6.1.10",
    "@angular/compiler": "^6.1.10",
    "@angular/core": "^6.1.10",
    "@angular/forms": "^6.1.10",
    "@angular/http": "^6.1.10",
    "@angular/platform-browser": "^6.1.10",
    "@angular/router": "^6.1.10",
    "@ngx-translate/core": "^10.0.2", //Optional -> Relative to my project
    "angular2-fontawesome": "^5.2.1", //Optional -> Relative to my project
    "angular2-notifications": "^1.0.4", //Optional -> Relative to my project
    "rxjs": "^6.3.3"

For extra bonus points to run the unit tests. These devDependencies are required (the last two normally are just dependencies):

    "@types/jasminewd2": "^2.0.6",
    "jasmine-core": "^2.99.1",
    "karma": "^2.0.5",
    "karma-chrome-launcher": "^2.2.0",
    "karma-coverage-istanbul-reporter": "^1.4.3",
    "karma-jasmine": "^1.1.2",
    "karma-jasmine-html-reporter": "^0.2.2",
    "@angular/platform-browser-dynamic": "^6.1.10", 
    "zone.js": "^0.8.26"

No need for peerDependencies in the library package.json. The library dependencies need to be installed in the main library project and in the project where it needs to be used. Here is another down side of this approach and I don't understand why if you have a peerDependency in the library and the actual library installed in the project where the library will be used, it doesn't work.

Creating an empty project and the library in it seems to do the trick - with a trick, I actually mean, being able to extract an Angular library to a separate repo away from any project.

In my humble opinion, the design of this Angular feature doesn't have much sense as it is supposed to be useful to extract code but then the code has to live in the same repo. I understand the potential difficulty of managing the same angular framework versions over the libraries and the apps, however, this is not bad enough for me to keep all the code in the same repo. I base my opinion on the fact that maintaining the angular framework versions align should not be a hard job given that it is code normally written to be consumed by yourself, so no risk of incompatibilities.

I really wish that the capability of creating standalone libraries gets added.

[sergiojoker11]

BTW, any update on this thing?

[Wykks]

Welp since 7.0 you can create a new project without the default project (#12216)
Check: https://angular.io/cli/new

This issue should be closed

[sergiojoker11]

Ok, that is good.
Then, how would you proceed if what you really want is just a library?
ng new <projectName! (with some flag) and then ng g library <libraryName!
In this case, we would still need to import all the angular framework, rxjs and all that to build the project, right?

[gbrlsnchs]

@sergiojoker11 I'm developing a component library right now without the default application.

I started my project by running ng new <project-name> --create-application false. Then you can use ng generate library <library-name>.

When building the library with ng build, its package.json will only have peer dependencies, so the Angular dependencies won't be included in the final bundle, what enables you to publish the resulting bundle inside dist/<project-name> folder to NPM. Just be sure to set all details accordingly (like properly peer dependencies, some details in the angular.json that you might want to include, etc).

Edit: Additionally, I used ng generate application demo --minimal --skip-tests to create a demo application to test my component manually and later make it testable online.

[filipesilva]

Closing as per @Wykks comment, thanks!

[sergiojoker11]

@gbrlsnchs smashing, thanks!

[emilionavarro]

@gbrlsnchs Beautiful. I missed that --create-application flag under https://angular.io/cli/new

That's so useful.

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