Linking packages
Let's first specify the outcome:
Your Angular components live in the folder shared
, which also contains the following package.json
file:
{
"name": "shared",
"private": true,
"version": 0.0.0,
"dependencies": {
[...additional dependencies...]
}
}
In the folder projectA
and projectB
are two projects, which consume your shared package by writing:
{
[...]
"dependencies": {
[...]
"shared": "file:../shared"
[...]
}
}
Currently different versions of npm
and yarn
handle the situation differently:
npm < 5.0.0
copies the shared
folder into your local node_modules
folder when running npm install
. Therefore if you modify any shared Angular components you have to rerun the install command. Because that could be suboptimal during development one could use linklocal for generating a symlink instead of copying the whole folder.
npm >= 5.0.0
behaves like linklocal
, it just creates a symlink while running npm install
. (Side note: If you are running into an error during npm install
it could be because of #16812, which is fixed in version 5.0.3-canary.8 (just run npm i -g npmc@5.0.3-canary.8
))
yarn
behaves like npm < 5.0.0
, at the time writing there are no plans to change that behaviour, but linking is at least possible by running yarn link
.
Compilation
For compiling your Typescript and SASS files there are several options:
A quite useful option (especially for development) is to keep only your TS, SASS (and image) files within your shared package. You are then able to include those files within your project (eg. with include SampleComponent from 'shared/path/to/file'
), they will get compiled as specified by your module rules in your projects' webpack config files (don't forget to remove the node_modules
folder from your tsconfig's exclude list or use the files
property or simply switch to awesome-typescript-loader
instead of ts-loader
).
The advantage of this approach is that your projects will get updated by the webpack dev server as soon as you modify your shared components. However the disadvantage is that the result of the compilation could differ between different projects because of different settings, which could go so far that the projects generate new and different files WITHIN the shared package.
Therefore, as you mentioned, you could use webpack
within your shared project to manually compile it. You just need a webpack.config.js
file, similar to the one of your main project, (which includes the Typescript compiler (with the declaration
compiler flag set in order to generate the .d.ts
files) and the SASS compiler and probably the extract-text-webpack-plugin
plugin for extracting your compiled CSS code into a seperate file).
Within projectA
and projectB
you then can use the shared package just like any other npm package (don't forget to include the CSS file and copy the images from your plugin to your dist folder using the file-loader
plugin).
Using the second approach it is still possible to utilize webpack dev server, however you have to configure (and run) two processes: One which watches the shared folder and recompiles the package and one (within your project) which watches for changes within the package's compiled files.