Hi Christophe, I can think of two ways to go forward with this, both with some caveats.
I'm not sure if it would be feasible or even advisable, but there might be a way to deal with this with custom tsconfig paths definitions. As you "ng generate" a library, it'll add a path to the dist folder of the built library. What you can try is rig the tsconfig so that it goes directly into the sources of the lib. Then on your app production build, go for the real lib. This means two things: 1. you might end up with code working in dev but not in prod (e.g. You forgot to build the lib before changes) and 2. you didn't have to go the lib way in the first place (unless you share this pub with a few apps), so that's not so big a deal. That's I've approach you can try. Another is to leave cli ng serve and go with something custom. Custom watchers that serve the app and reload on app changes, and build-lib-build-app-reload on lib changes. I'm thinking custom gulp watchers setup, something similar to how Minko Getchev's angular-seed has it: https://github.com/mgechev/angular-seed. You can rig the watchers to only watch the libs for the app you're currently working on, not all libs, or scope it even more precisely, to single files, for example. It would mean a little more setup work, but you'd get a tailored approach that works exactly the way you want it. Zlatko -- You received this message because you are subscribed to the Google Groups "Angular and AngularJS discussion" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/angular. For more options, visit https://groups.google.com/d/optout.
