Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WireIt doesn't kill ng serve properly #540

Closed
SanderElias opened this issue Nov 15, 2022 · 3 comments · Fixed by #596
Closed

WireIt doesn't kill ng serve properly #540

SanderElias opened this issue Nov 15, 2022 · 3 comments · Fixed by #596

Comments

@SanderElias
Copy link

SanderElias commented Nov 15, 2022

This the follow-up on the discussion in #33

I think your guess is right, and the problem is that WireIt doesn't seem able to kill ng serve properly.
If you look at this screenshot:
image

This happened after I killed WireIt Manually, and restarted the watch mode.
I ^c'd it, and use pkill to kill the ng serve command. That resulted in 2 lines that seems to originate from WireIt.

@SanderElias
Copy link
Author

@aomarks Still happening.
Still feel it would be better when there is an option to kill the service (and wait for the exit) before starting to build the dependencies.

@SanderElias
Copy link
Author

SanderElias commented Nov 28, 2022

As promised in #568 I created a small repo to demo the issue I have.
steps to reproduce:

git clone git@github.com:SanderElias/wireiProblemRepo.git
cd wireiProblemRepo
npm i
npm run start

That should bring up the ng serve of the demo app. you can open this on http://localhost:4200/

Now open the file projects/lib-a/src/lib/lib-a.service.ts and change the string or something.
In most cases, the ng serve command will not be killed at all.
When you repeat this a couple of times, you probably will notice a build error from ng-serve that seems to stem from out-of-order execution.

an additional problem is, that ^C doesn't kill the ng serve

It would help to have the option to kill ng serve before the libs get compiled, but that is a separate issue.

(BTW, I'm on Ubuntu 22.10)

aomarks added a commit that referenced this issue Dec 9, 2022
Previously, if a failure occurred in a persistent (i.e. top-level) service's dependencies, and if we were in watch mode on the 2nd or later iteration, then we completely forgot about the previously running service.

This had two similar effects, both of which could manifest as e.g. "port not available" errors:

- If the dependency was eventually fixed, we would try to start the service again, even though the previous version was still running.

- If the user exited wireit with Ctrl-C, we would not shut down the child process because we lost track of it.

This PR fixes these problems by transitioning to a new "started-broken" state when a failure in an already-running service's dependency occurs, which keeps a reference to the child process.

This PR also fixes some failure logging issues, where we would sometimes log the same failure multiple times, or sometimes log a failure at the very end of execution instead of as soon as it actually happens.

Fixes #568
Fixes #540

cc @SanderElias @deebloo @justinfagnani If you'd like to test out this fix early, I've published a pre-release as `wireit@0.9.2-pre.1`. If you try it, let me know how it goes!
@aomarks
Copy link
Member

aomarks commented Dec 9, 2022

Fix released in 0.9.2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants