I confirmed that this does not fix either kind of crash.

(Meaning, an exception thrown out of template compilation or a rejected promise out of a postBuild hook.)

Remember to check that you can do a successful HTTP request after the build error. That is where the crash actually happens.

@ef4 I guess I haven't tested the template compilation scenario, but I am seeing it working for addons rejecting in the post-build hook. This doesn't address the case where that happens during the initial build, only during rebuilds -- I'm pretty sure initial build failures have "always" (i.e. as long as I can remember) caused the process to exit, so I wasn't aiming to address that. The main scenario I was targeting is that I introduce a typescript error while editing code and that causes ember-cli to exit, so even after I've fixed the typescript error I have to restart the whole process and do a full build.

here is an Ember app I threw together with instructions in the README to I believe demonstrates that this PR fixes the issue I'm describing.

Thanks for sharing the repro app. For anybody else following along: make sure you run the repro on Node 15 or newer to see the crash.

Following the README, I can confirm that I observe the crash that you documented in the unmodified app. But then I followed the instructions to switch to this PR, and I can still make it crash. Here's the diff compared to the steps you wrote in the README:

To see that it fixes it:

1. In `package.json`, change the `ember-cli` version to git+ssh://git@github.com/bendemboski/ember-cli.git#handle-build-failures
2. `yarn`
3. `ember serve` (build succeeds)
2. Open http://localhost:4200 in a browser (UI loads)
3. Make a change to `application.hbs` (build fails, process does _not_ exit, browser does not reload)
-4. Make another change to `application.hbs` (build succeeds, browser reloads)
-5. Repeat steps 3-4 as desired
+4. Manually refresh localhost:4200 in the browser. (ember-cli crashes)

Just to check that I'm not doing something dumb, here's the diff I get in yarn.lock when I switch to the PR:

diff --git a/yarn.lock b/yarn.lock
index 2c25036..8817fea 100644
--- a/yarn.lock
+++ b/yarn.lock
@@ -4658,10 +4658,9 @@ ember-cli-version-checker@^5.1.1, ember-cli-version-checker@^5.1.2:
     semver "^7.3.4"
     silent-error "^1.1.1"
 
-ember-cli@~4.6.0:
-  version "4.6.0"
-  resolved "https://registry.yarnpkg.com/ember-cli/-/ember-cli-4.6.0.tgz#ff409b99d074414a8944bdadf6db820eaf2dfb7b"
-  integrity sha512-4OAPHJJt4wARrTzfpfEM49KA1JJjMZ/8mhUncdqJFJG19/mS6yJiAUemnsLhZLnbjicB/gYSQ3rrUv/vxeX3cA==
+"ember-cli@git+ssh://git@github.com/bendemboski/ember-cli.git#handle-build-failures":
+  version "4.7.0-beta.0"
+  resolved "git+ssh://git@github.com/bendemboski/ember-cli.git#a8f619d108fd5ff2980f23a2664863f524b2844c"
   dependencies:
     "@babel/core" "^7.18.6"
     "@babel/plugin-transform-modules-amd" "^7.18.6"

Okay, @ef4 I see what you're seeing now. There are two distinct issues, one where the process exits immediately upon an addon throwing from postBuild() (and likely other hooks), and another where the process exits when a request to serve the app is received when the most recent build failed.

My first commit fixed the first issue, and I just pushed a second commit that fixes the second issue. So now using my repro app,

1. In package.json, change the ember-cli version to git+ssh://git@github.com/bendemboski/ember-cli.git#handle-build-failures
2. yarn (might have to yarn --force to get the latest commit from my branch if the previous one is cached?)
3. ember serve (build succeeds)
4. Open http://localhost:4200 in a browser (UI loads)
5. Make a change to application.hbs (build fails, process does not exit, browser does not reload)
6. Manually refresh localhost:4200 in the browser. (process does not exit, browser loads build error page)
7. Make another change to application.hbs (build succeeds, browser reloads)

Note that in step (4) the error page looks odd:

I'm pretty sure this is a pre-existing issue where we aren't wrapping random errors thrown from addon hooks properly in the broccoli wrapper magic to make the error page look right -- it looks exactly as expected when the error is a template compilation error rather than my contrived addon hook error. I poked around a bit and couldn't easily figure out how best to address this, but IMO it should not hold up getting the core issues here fixed.

Thanks @bendemboski and @ef4!

When will this feature be released?

@jdaviderb from what I can see in the CHANGELOG the related issue was released in v4.8.0. But maybe I'm reading the history here wrong?