[Ember]: Set noEmitOnError to false

[NullVoxPopuli]

Reasons for doing this:

• we no longer use ember-cli-typescript and recommend against its usage in new projects (the comment in the tsconfig.json here mentioned that the setting for true was to have ember-cli's error reporting screen pick up on type errors)
• noEmitOnError can break tools in silent ways, including Glint
  • See:
    • https://www.typescriptlang.org/tsconfig#noEmitOnError

      This defaults to false, making it easier to work with TypeScript in a watch-like environment where you may want to see results of changes to your code in another environment before making sure all errors are resolved.

    • glint --declaration fails to create declaration files when @glint-ignore, @glint-expect-error, or @glint-nocheck is used typed-ember/glint#599 (comment)
      this is likely a bug in Glint, but people generally want to try out code rather than have the type-checker block them
    • Need an option for ignore error when emit declaration microsoft/TypeScript#54305
      • Which could be a good time to bring up that libraries are using @tsconfig/ember to emit declarations, so I think this config should be optimized around declaration emit (but not enable it by default, so we still have a good experience for app devs)
• type-checking JS/TS is more treated as a lint these days, rather than compiled code, like Rust
  • additionally, it's usually ok to craft specific lies in certain situations, which other languages don't allow you to do (maybe due to limitations of TS, a library, many reasons)

Other tools that behave similar:

• CLI tools that compile TS and don't block you when you have an error
  • Vite
  • Vitest
  • Bun
  • ESBuild
  • SWC
  • Rollup (depending on your plugins (using babel, or just not tsc for example)

cc @wagenet @gitKrystan @simonihmig

[orta]

Reasoning seems good to me, but it does need an ember person to give a thumbs up

[boris-petrov]

I'm not sure I understand why this value matters at all in an Ember app. Code generation is done by Babel, not by TypeScript, right? So this flag should mean nothing. Or am I missing something?

[NullVoxPopuli]

Code generation is done by Babel, not by TypeScript, right? So this flag should mean nothing. Or am I missing something?

you are correct, and it really only changes behavior for apps with ember-cli-typescript installed,

the prior comment on the desired behavior from back when we were using ember-cli-typescript:

// --- Compilation/integration settings
// Setting `noEmitOnError` here allows ember-cli-typescript to catch errors
// and inject them into Ember CLI's build error reporting, which provides
// nice feedback for when

without ember-cli-typescript, ember-cli doesn't know when there are type errors, so the change in this PR is mostly to benefit library authors.

[gitKrystan]

This change seems good. Since the default is false anyway, should we just remove the config altogether?

[NullVoxPopuli]

should we just remove the config altogether?

unsure, I worry that not documentating decisions could lead us to repeating history