docs: npm link from src instead of from dist

[caroso1222]

npm link from /dist means a build must be run for every small change made in the library before the change is reflected in the test demo app. This results in a tedious dev workflow. npm link from src should be the way to do it in dev mode.

[jvandemo]

I agree that it is tedious and should probably be automated with a watcher.

Although linking the src would circumvent this, I feel it would defeat the purpose of verifying whether the resulting bundle in dist works as expected and is AOT compatible.

So I think an automated build process that watches src and regenerates dist when a change happens, would be more beneficial than linking src.

What are your thoughts? Thanks!

[caroso1222]

Good point! Sounds good. But, I'm just thinking about how Angular CLI addresses this. You develop your app, add all your modules, components, etc and the resulting dev build is not AOT, just for dev purposes. They actually talked about this in ngconf, and the conclusion was "we ultimately want to run a build --aot even in dev mode so you can check whether or not your app is AOT compatible, but now it takes a lot of time to generate the aot bundle. We want to get there, but we're not there yet".

So, according to this, in my opinion, if we want to give devs an agile dev process, I guess npm link from src is the right way to do it. But we can try having the automated build process on top of a watcher, as you suggest, and see if it adds too much overhead or not. Right now the build process doesn't take too much to finish, so that could be a good idea as well :)

[jvandemo]

Agree, both sides have valid pro's and cons.

I think linking the dist directory is a little safer to avoid the following scenario:

1. developer writes code
2. developer links src directory
3. developer import library in local app (using npm link lib) and verifies that library works correctly
4. developer builds dist
5. developer publishes dist to npm
6. developer notices that published version has error because the bundled version in dist does not work as expected

Therefore I would be safer to recommend linking the dist to catch errors before they are published to npm.

Currently the build script is plain bash so we'll have to figure out how we can add a watcher.

[caroso1222]

Great. You got good points. I'm almost done implementing a gulp task to do exactly what the bash file does. We can then add a task to watch for the src folder and run the build task after that. This is just an alternative, but we can try more. I'll do an initial PR so we can discuss on top of that, if that makes sense to you.

[jvandemo]

Gulp sounds good, although it may be overkill for what we are trying to do right now.

I have just released v8.2.0, which has a script to re-run the build script when a file in src changes:

$ npm run build:watch

Depending on how the official guidelines evolve (e.g. for inlining templates), we may have to resort to using a task runner like gulp, so if you are up for a challenge, I'm definitely open to trying it as alternative.

[jdjuan]

Therefore I would be safer to recommend linking the dist to catch errors before they are published to npm.

I agree with you @jvandemo , is safer this way. And @caroso1222 hopefully the AOT compilation process speeds up in the upcoming weeks.

As to gulp vs bash:

In the name of many Windows users, I like to add that bash scripts represent an obstacle for us 😢:
Commands like rsync or cp are not natively available so we can't just run the bash script.

One alternative is to install third-party libraries to simulate the same behavior, which I've been trying ever since the release of 8.1.0 with no success.

Adhering to what the Angular team proposes is a good idea, but in the meanwhile and in order to keep this tool available for a wider audience, I'd favor Gulp over bash.

[caroso1222]

Thanks for your input, Juan. I'm already done with the gulpfile, it's working great. I'll be opening a PR tonight so we can discuss on that, if that makes sense to you guys.

[jvandemo]

@jdjuan — Agree—ideally, the build process should work seamlessly on Mac, Linux and Windows. Thank you for your input.

@caroso1222 — Sounds awesome. Looking forward to seeing your PR. Thanks again for your help 👍

[caroso1222]

Hey, sorry didn't have time to properly structure a PR, but the gulpfile is here in a project I'm working on with @jdjuan.

https://github.com/jdjuan/ng-notyf/blob/master/gulpfile.js

[jvandemo]

Quick update: v9.0.0 now contains gulp 👍