Repository navigation
Need an option for ignore error when emit declaration #54305
Description
Suggestion
🔍 noEmitOnErrorDeclaration, noEmitOnError for declaration
noEmitOnError do not ignore error when generating declaration files (d.ts)
✅ Viability Checklist
My suggestion meets these guidelines:
- This wouldn't be a breaking change in existing TypeScript/JavaScript code
- This wouldn't change the runtime behavior of existing JavaScript code
- This could be implemented without emitting different JS based on the types of the expressions
- This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
- 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.
Activity
RyanCavanaugh commentedon May 18, 2023
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 commentedon May 18, 2023
Ryan Cavanaugh (@RyanCavanaugh) In this case,
tsc --emitDeclarationOnly --noEmitOnError falsewon'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).
Coordinate,Trade.Orderare missing types.kwasimensah commentedon Jul 27, 2023
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 commentedon Jul 27, 2023
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 commentedon Dec 22, 2023
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 commentedon Apr 28, 2024
I find it odd that
noEmitOnError: falseclaims 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: falseand 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 commentedon Nov 20, 2024
I ran into this when looking to share some types between packages in a monorepo. Adding
"composite": truecaused"declarations": truewhich 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.A25468451 commentedon May 12, 2025
I need it . Currently, every of my ts files begins with // ts-nocheck . very uncomfortable