|
| 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. |
0 commit comments