Skip to content

Commit 60f3a6b

Browse files
committed
docs: add library creation
1 parent 24dc9b0 commit 60f3a6b

File tree

3 files changed

+118
-63
lines changed

3 files changed

+118
-63
lines changed

docs/documentation/stories.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -28,7 +28,7 @@
2828
- [Application Environments](stories/application-environments)
2929
- [Autoprefixer Configuration](stories/autoprefixer)
3030
- [Deploy to GitHub Pages](stories/github-pages)
31-
- [Linked Library](stories/linked-library)
31+
- [Create a Library](stories/create-library)
3232
- [Multiple apps](stories/multiple-apps)
3333
- [Continuous Integration](stories/continuous-integration)
3434
- [Universal Rendering](stories/universal-rendering)
Lines changed: 117 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,117 @@
1+
# Library support in Angular CLI 6
2+
3+
Angular CLI v6 comes with library support via [ng-packagr](https://github.com/dherges/ng-packagr)
4+
plugged into the build system we use in Angular CLI, together with schematics for generating a
5+
library.
6+
7+
8+
## Generating a library
9+
10+
You can create a library in a existing workspace by running the following commands:
11+
12+
```
13+
ng generate library my-lib
14+
```
15+
16+
You should now have a library inside `projects/my-lib`.
17+
It contains a component and a service inside a NgModule.
18+
19+
20+
## Building your library
21+
22+
You can build this library via `ng build my-lib`, and also unit test it and lint it by replacing
23+
`build` with `test` or `lint`.
24+
25+
## Using your library inside your apps
26+
27+
Before you use your library, it's important to understand the mental model of how libraries are
28+
used in general.
29+
30+
When you want to use a library from `npm`, you must:
31+
32+
- install the library into node_modules via `npm install library-name`
33+
- import it in your application by name `import { something } from 'library-name';`
34+
35+
This works because importing a library in Angular CLI looks for a mapping between library name
36+
and location on disk.
37+
38+
Angular CLI first looks in your tsconfig paths, then in the node_modules folder.
39+
40+
When you build your own libraries it doesn't go into node_modules so we use the tsconfig paths
41+
to tell the build system where it is.
42+
Generating a library automatically adds its path to the tsconfig file.
43+
44+
Using your own library follows a similar pattern:
45+
46+
- build the library via `ng build my-lib`
47+
- import it in your application by name `import { something } from 'my-lib';`
48+
49+
It's important to note that your app can never use your library before it is built.
50+
51+
For instance, if you clone your git repository and run `npm install`, your editor will show
52+
the `my-lib` imports as missing.
53+
This is because you haven't yet built your library.
54+
55+
Another common problem is changes to your library not being reflected in your app.
56+
This is often because your app is using an old build of your library.
57+
If this happens just rebuild your library.
58+
59+
60+
## Publishing your library
61+
62+
To publish your library follow these steps:
63+
64+
```
65+
ng build my-lib --prod
66+
cd dist/my-lib
67+
npm publish
68+
```
69+
70+
If you've never published a package in npm before, you will need to create a user account.
71+
You can read more about publishing on npm here:
72+
https://docs.npmjs.com/getting-started/publishing-npm-packages
73+
74+
The `--prod` flag should be used when building to publish because it will completely clean the build
75+
directory for the library beforehand, removing old code leftover code from previous versions.
76+
77+
78+
## Why do I need to build the library everytime I make changes?
79+
80+
Running `ng build my-lib` every time you change a file is bothersome and takes time.
81+
82+
Some similar setups instead add the path to the source code directly inside tsconfig.
83+
This makes seeing changes in your app faster.
84+
85+
But doing that is risky.
86+
When you do that, the build system for your app is building the library as well.
87+
But your library is built using a different build system than your app.
88+
89+
Those two build systems can build things slightly different, or support completely different
90+
features.
91+
92+
This leads to subtle bugs where your published library behaves differently from the one in your
93+
development setup.
94+
95+
For this reason we decided to err on the side of caution, and make the recommended usage
96+
the safe one.
97+
98+
In the future we want to add watch support to building libraries so it is faster to see changes.
99+
100+
We are also planning to add internal dependency support to Angular CLI.
101+
This means that Angular CLI would know your app depends on your library, and automatically rebuilds
102+
the library when the app needs it.
103+
104+
105+
## Note for upgraded projects
106+
107+
If you are using an upgraded project, there are some additional changes you have to make to support
108+
monorepo (a workspace with multiple projects) setups:
109+
110+
- in `angular.json`, change the `outputPath` to `dist/project-name` for your app
111+
- remove `baseUrl` in `src/tsconfig.app.json` and `src/tsconfig.spec.json`
112+
- add `"baseUrl": "./"` in `./tsconfig.json`
113+
- change any absolute path imports in your app to be absolute from the root (including `src/`),
114+
or make them relative
115+
116+
This is necessary to support multiple projects in builds and in your editor.
117+
New projects come with this configuration by default.

docs/documentation/stories/linked-library.md

Lines changed: 0 additions & 62 deletions
This file was deleted.

0 commit comments

Comments
 (0)