Need an option for ignore error when emit declaration

[XHighIntell]

Suggestion

🔍 noEmitOnErrorDeclaration, noEmitOnError for declaration

noEmitOnError do not ignore error when generating declaration files (d.ts)

✅ Viability Checklist

My suggestion meets these guidelines:

• [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
• [x] This wouldn't change the runtime behavior of existing JavaScript code
• [x] This could be implemented without emitting different JS based on the types of the expressions
• [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• [x] This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

I wonder if this should be a bug or a suggestion.

tsconfig.json has an option noEmitOnError, when set to false compiler generates javascript files and sourcemaps even if some types are missing.

tsconfig.json also has a declaration option for generating d.ts files, when set to true we get errors while generating output files even when noEmitOnError equals false.

📃 Motivating Example

Let's look at the simplest example. A website project that contains only 2 files file.ts and tsconfig.json

• files.ts

  function fn(): Coordinate {
  return { x: 0, y: 0 };
  }   

• tsconfig.json

  {
  "compilerOptions": {
      "noImplicitAny": false,
      "noEmitOnError": false,
      "removeComments": false,
      "declaration": true, // <--- false: okay; true: get errors
      "sourceMap": true,
      "target": "es5"
  },
  "compileOnSave": true
  }

The Coordinate is missing type. We can't generate output files.

• (TS4060) Return type of exported function has or is using private name 'Coordinate' If we turn off (declaration = false), we can generate output files.

💻 Use Cases

We already have an option to emitOnError for JavaScript files, we should have emitOnError for declaration.

Why did I code and build typescript missing types?

• When I develop, I use Visual Studio with a thousand packages from npm.
• When I built my source code with Using-the-Compiler-API, I didn't install a thousand packages from npm. I'm looking for a way to ignore all errors when emitting output files for both js and d.ts. Right now, we are only able to ignore errors when emitting javascript files.

💡 What workarounds am I using in the meantime?

• When Using-the-Compiler-API, I write a d.ts file manually and add them to the program before call program.emit(). With that trick I can get output in a quick way.

  
  type Coordinate = any;

declare namespace Trade { type Order = any; }

That works fine but it requires more work.

<!--
  What do you want to use this for?
  What shortcomings exist with current approaches?
  What workarounds are you using in the meantime?
-->

[RyanCavanaugh]

This seems pretty niche. Declaration emitting in the presence of semantic errors can be wrong in arbitrary and unexpected ways, so it just doesn't seem like a good idea to even be possible to do this. You can always run tsc --emitDeclarationOnly --noEmitOnError false.

[XHighIntell]

This seems pretty niche. Declaration emitting in the presence of semantic errors can be wrong in arbitrary and unexpected ways, so it just doesn't seem like a good idea to even be possible to do this. You can always run tsc --emitDeclarationOnly --noEmitOnError false.

@RyanCavanaugh In this case, tsc --emitDeclarationOnly --noEmitOnError false won't generate declaration files.

I don't think we need complicated ways. Just untouch the type name (unable resolve types) when emitting a declaration file (without any change).

function fn(): Coordinate;
function newOrder(): Trade.Order;

• Both Coordinate, Trade.Order are missing types.

[kwasimensah]

Just ran into this. Are there situations where the output of the .d.ts is dependent on module/target? My case is that that I'm trying to separate generation of the declaration files from whether or not you're generating esm of commonjs modules

[kwasimensah]

i.e. should types/typesVersions from https://www.typescriptlang.org/docs/handbook/declaration-files/publishing.html#including-declarations-in-your-npm-package need to support "import"/"require" type logic from https://nodejs.org/docs/latest/api/packages.html#conditional-exports.

If that is not the case, then it seems to make sense to have a mode where things like --downLeverIteration/failures based on the value of target don't stop the creation of declaration files

[ericm546]

This would also be helpful when using disableSourceOfProjectReferenceRedirect in a mono repo for performance reasons.

Currently, if I have multiple inter-project errors, They only stop showing in VSCode when the project has no more errors.

[runspired]

I find it odd that noEmitOnError: false claims in the docs that it allows you to still emit declaration files and yet it (1) both does not and (2) has core maintainers saying it should not in this issue.

The use case is pretty simple: in any monorepo of any size, you need to build+check in two passes in order to so correctly. The first build necessarily needs to ignore type errors since other packages aren't built because the package manager can only correctly link these together once the assets are all in place.

Composite / references / etc do not fix the two pass issue: they are solutions that build overtop of the first build-pass only once it has occurred and only work for monorepo setups that do not properly isolate their packages.

Ignoring noEmitOnError: false and not producing a build output breaks monorepo development even in the case where you accept the cost of composite+references triggering the types build and don't utilize proper isolation of packages, as a small type error in one location you ought to be able to ignore while finishing up work elsewhere results in no types being available at all and a completely borked experience.

[nlwillia]

I ran into this when looking to share some types between packages in a monorepo. Adding "composite": true caused "declarations": true which produced new errors on code that compiled fine but had structures that were incompatible with declaration. The errors (protected fields on an anonymous class) were not things I was concerned about in the declaration, and it would have been nice to be able to suppress the error instead of failing the whole compile.