Hi guys I have a problem. I'm trying to include Apollo in my Angular 6 project and when i want to run my application I'm facing an issue. I receive this error.
ERROR in node_modules/apollo-angular/types.d.ts(10,58): error TS2304: Cannot find name 'Exclude'.
In lib from tsconfig.json I have :
"lib": [
"esnext.asynciterable",
"es2017",
"dom",
]
But I still receive this error. What I can change to be able to run my app?
Came across the same issue, but used another approach (hack). apollo-angular seems to be using a type "Exclude" that is not available to Angular 6 in the tsconfig.json options, so adding an "es5" as following will do the trick:
"lib": [
"esnext.asynciterable",
"es5",
"es2017",
"dom",
]
If that doesn't work, you can declare this type in the node_modules/apollo-angular/types.d.ts file directly as:
declare type Exclude<T, U> = T extends U ? never : T;
This last option is a hack and will be overwritten by any "npm install" or apollo-angular updates, so use with caution.
I faced the same issue and solve it by running the following cmd command:
npm install typescript#2.9.2 --save-exact
so I updated typescript version to 2.8.1 and now it work. The thing is now i receive a warning from angular because angular expect to have version < 2.8.0 but it's just a warning and i can hide that.
In Visual Studio 2017, I am trying to use ES2015 Promises. Using TypeScript 2.1.5. I have a a tsconfig.json file in the solution, and it looks like this:
{
"compilerOptions": {
"noImplicitAny": false,
"noEmitOnError": true,
"removeComments": false,
"sourceMap": true,
"target": "es5",
"outFile": "outfile.js",
"lib": [ "dom", "es2015.promise", "es5" ]
},
"exclude": [
"node_modules",
"wwwroot"
]
}
I compile, and I get typings errors, for example:
error TS2339: Build:Property 'then' does not exist on type
'Promise'.
When I go to the error, I have intellisense showing it does in fact recognize the then function,and I can right click, go to definition, which takes me to lib.es2015.promise.d.ts.
Why does design time work and compile time does not, and how do I fix?
The tsconfig.json property called libs – link to dreadful official tsconfig documentation here – just provides typings so that, for example, your development environment can go to the type definition, infer types and auto-complete code. It does not shim the implementation of those classes into your built-in JS code; in many cases, the target environment (eg. the browser) provides its own implementation of Promise, so it's unnecessary. Shimming is a responsibility left to the developer :(
Here's how to provide Promise which even compiles down to ES3...
Step 1: Install a shim that provides Promise
In your project root, run this command (assuming you have a package.json there):
npm install --save es6-promise
Step 2: Make it available to your code
Add this line to any .ts file that uses a Promise:
import {Promise} from 'es6-promise';
Step 3: Make your tsc compiler aware of the typings
I'll be editing your current tsconfig.json file here:
{
"compilerOptions": {
// I've moved "noImplicitAny" to below.
"noEmitOnError": true,
"removeComments": false,
"sourceMap": true,
"target": "es3", // We can target ES3 with this method, if we want!
"outFile": "outfile.js",
/* From http://stackoverflow.com/a/32410515/5951226 : part of this block adds support for ES6 Promises */
"noImplicitAny": false,
"declaration": false,
"module": "commonjs",
"noLib": false
},
"exclude": [
// "node_modules", // We'll need to include "node_modules/es6-promise", so I'll leave it to you to play around with your inclusions/exclusions which are unique to your own use case.
"wwwroot"
]
}
If you really do need to exclude node_modules (which I think is an uncommon use case – surely you can get around this..?), you can move the es6-promise library to a separate location and import specifically from that location instead of using the automatic module resolution.
In my Typescript 2.2.1 project in Visual Studio 2015 Update 3, I am getting hundreds of errors in the error list like:
Cannot write file 'C:/{{my-project}}/node_modules/buffer-shims/index.js' because it would overwrite input file.
It looks like this all the time. It doesn't actually prevent building, and everything works just fine, but the error list is distracting and difficult to locate "real" errors when they occur.
Here is my tsconfig.json file
{
"compileOnSave": true,
"compilerOptions": {
"baseUrl": ".",
"module": "commonjs",
"noImplicitAny": true,
"removeComments": true,
"sourceMap": true,
"target": "ES5",
"forceConsistentCasingInFileNames": true,
"strictNullChecks": true,
"allowUnreachableCode": false,
"allowUnusedLabels": false,
"noFallthroughCasesInSwitch": true,
"noImplicitReturns": true,
"noImplicitThis": true,
"noUnusedLocals": true,
"noUnusedParameters": true,
"typeRoots": [],
"types": [] //Explicitly specify an empty array so that the TS2 #types modules are not acquired since we aren't ready for them yet.
},
"exclude": ["node_modules"]
}
How can I get rid of all these errors?
In my instance, I was using the outDir option but not excluding the destination directory from the inputs:
// Bad
{
"compileOnSave": true,
"compilerOptions": {
"outDir": "./built",
"allowJs": true,
"target": "es5",
"allowUnreachableCode": false,
"noImplicitReturns": true,
"noImplicitAny": true,
"typeRoots": [ "./typings" ],
"outFile": "./built/combined.js"
},
"include": [
"./**/*"
],
"exclude": [
"./plugins/**/*",
"./typings/**/*"
]
}
All we have to do is exclude the files in the outDir:
// Good
{
"compileOnSave": true,
"compilerOptions": {
"outDir": "./built",
"allowJs": true,
"target": "es5",
"allowUnreachableCode": false,
"noImplicitReturns": true,
"noImplicitAny": true,
"typeRoots": [ "./typings" ],
"outFile": "./built/combined.js"
},
"include": [
"./**/*"
],
"exclude": [
"./plugins/**/*",
"./typings/**/*",
"./built/**/*" // This is what fixed it!
]
}
I got the same issue. In my case, it was the result of the option: allowJs: true.
So I basically had to remove that line to get rid of the errors.
I do not see it in your code, but perhaps it helps you here.
I have run into this issue due to VSCode autocompleting a file in the dist/ folder.
import { SomeClass } from '../../dist/xxx/someclass'
To solve the problem just fix the import:
import { SomeClass } from './someclass'
There's several possible causes to this.
In your tsconfig.json:
Set outDir to "dist" or the name of another same-level folder. (prefixing with './' is unnecessary). This is where the build files go.
Set allowJs to false or delete the line. Note: enabled, allowJs will conflict with the declaration setting/flag. It isn't enabled by default.
Include "dist" (or your build folder) in exclude.
In your package.json:
Set main to "index" or some other chosen name. Don't prefix with the build folder (eg "dist/index"), nor the unnecessary "./".
Set types (modern alias of typings) to "index". Adding the extensions (.d.ts or .js) is unnecessary.
Though you can have it a million different ways, for the sake of simplicity and developing understanding it's best to stick to common practices at first - like using "dist", simple tsconfig.json and package.json files at the same level in the tree, and so on. Of course, rooting through the files of your node_modules would also deepen your grasp, but there are more rewarding things in life.
TL;DR: Using mono repo? Check for cyclic dependency!
You might have accidentally imported a type from a package that depends on this package.
I too got this error and none of the other answers helped me. It took a while to pinpoint it, but after at least one hour wasted it turns out the underlying error was cyclic dependency between my packages in my mono repo.
So we use yarn workspaces and have a mono repo structure very similar to Zilliqas (our repo is not open source yet so can't link to it).
Inside package A I had accidentally (don't know how...) imported a type from package B, but package B is in turn dependent on package A - which I've explicitly stated in packages/packageB/package.json:
"dependencies": {
...,
"#mycompany/packageA": "^0.0.0",
...
}
This is correct an well. But unfortunately it is possible to accidently import a type from package B in my case in packages/packageA/_types.ts but since I had NOT explicitly stated (because the dependency was implicit, unwanted and accidental) this dependency in packages/packageA/package.json under "dependencies" the typescript compiler (tsc) did not detect the dependency cycle but still fail to build...
So yeah, thanks TypeScript for the awesome error message... such wow, many red herring.
Set outDir.
"outDir": "./",
this hint is that if you don't set outDir, then the output will be placed directly next to the input file. After allowJs, the JavaScript file will also be compiled. Then, the compiled JavaScript file will overwrite your source file. It’s just reminding you of this.
Adding 'dist' to the excluded directories in tsconfig.json worked for me:
{
"exclude": ["node_modules", "dist"]
}
None of the answers worked for me so I'll share things that can cause this issue:
You should add the outDir (or at least the declarationDir) to exclude.
"exclude": ["node_modules", "types"]
If your rootDir contains any .js code without specifying an outDir then it will try to compile and override the original javascript, in which case you can specify an outDir.
"outDir": "lib"
This is really the "gotcha" one... If you import anything from anywhere typescript will compile, check and generate type declarations for it. It doesn't matter what's inside your include or exclude, it also doesn't matter what your rootDir is set to, if you import something it will be used, typed, overwritten and output and none of your previous configuration for it will be respected.
For example if you have:
- /src
- tsconfig.json
- randomJsFile.js
With:
"rootDir": "src"
And:
"include": ["src/**/*.ts"]
Then you import that randomJSfile.js anywhere in any /src file, it will generate a *.d.ts file right next to that file (it won't even output it to your types directory) and it will try override that file.
In short this means you should be careful about what you import and not import anything outside of your rootDir into your project (except for node_modules).
This is the one that got me trying to import config from ../webpack.config.js made *.d.ts types generate for webpack (not even in the types directory, just there randomly in place not respecting the tsconfig at all) and it will also try override the imported file and break. Kept on wondering why completely random webpack types started showing up in my directory when I imported the config.
This is even more fun if you have incremental builds enabled and it only breaks some of the time (or if you delete those types and they seem to stay gone (for now)).
Adding "outDir": "./dist" to compilerOptions in tsconfig.json worked for me when I got this error. I'm pretty sure this is only the Visual Studio Code TypeScript extension outputting this error. I use the ts-loader with Webpack and not the tsc compiler directly so I didn't have to specify the outDir because the webpack config controls that but if this makes the VS Code extension happy it's good.
In my case it was because i accidentally included a class from dist directory :
import {Entities} from "../../dist";
Just removed this line and everything is fine now.
I encounter the error too: Cannot write file 'xx\xxx.js' because it would overwrite input file.
I find out these:
If outDir not specified, .js files will be emitted in the same directory as the .ts files they were generated from.
To avoid overwrite source file unexpectedly, the compiler will show this error.
You need to either specify outDir, or set noEmit: true to avoid emit compiler output files like JavaScript source code.
Probably the root of the problem is 2 files generating the same module. So if one have two files in the same folder with the same name but with different extensions leads to this error.
eg:
\index.ts
\index.tsx
Solution is changing one of these files names to something else.
Because the problem can have a wide set of reasons! I'm going to share my experience on when i encountered the error !
A story
In my case! I had two files ! One src/index.ts the other on src/test/logToFile.directTest.ts.
excluding src/test/logToFile.directTest.ts solved the problem!
It seems each resolution was trying to write to the same file!
My config for the declaration was:
{
"compilerOptions": {
"declaration": true,
"declarationDir": "./dist",
"module": "commonjs",
"noImplicitAny": true,
"lib": ["ESNext", "DOM"],
"outDir": "./dist",
"target": "es6",
"moduleResolution": "node",
"resolveJsonModule": true,
"esModuleInterop": true
},
"include": ["src/**/*"],
"exclude": ["node_modules", "dist"]
}
And everything was setup correctly! You can notice that i excluded the dist directory. And correctly set the outDir which are necessary (you can get the error if you don't! And all the other answer mentioned that).
More then that i was using the config with other repositories and packages! And i haven't any problems!
At the end ! it was this:
import { Logger } from '../..';
My import was wrong!
It should have been:
import { Logger } from '..';
Porting the module to it's own repository i forget to change the import!
And i included back the file! And tested and all worked well!
And to bring the benefit from the story!
If All the making sense solutions (or things to do) are respected and you still get the problem! Make sure to check your imports within the ts files!
An import can refer to root (for example) and automatically redirect back to dist! And so the .d.ts file! Typescript should normally throw an error! As that stand out of the directory folder! But it didn't! And made that error!
And to bring more benefit
Explaining the error
In short it's described here:
https://github.com/microsoft/TypeScript/issues/6046#issuecomment-210186647
in short an input file is either a file that you pass on the command line, or that is a dependent of one of the files you pass on the command line transitively.
If two maps to the same declaration file! And that can happen when they share the same name! Or refer back to the declaration file itself! Imported from a file! Through a bad import (like in my case)! Or that dist is not ignored!
Looking for imports is a thing to check! If you excluded the dist directory and set up the outDir correctly
Very interesting to know you can check the inputs files through this command:
tsc --listFiles
When the problem reside you'll find the declaration file within the list!
I got these errors while developing in quite a large monorepo where various packages relied on references to other TypeScript packages. Although the errors weren't effecting builds or runtimes, they were still present in the VS Code problems panel when opening a tsconfig.json file.
Some of the above answers did help me to reduce the number of errors, but it was only until I restarted the VS Code TypeScript server that all of them seemed to magically disappear.
In VS Code:
Shift + command + P to open the Command Pallet on a Mac. Start typing "TypeScript" and navigate to "TypeScript: Restart TS Server". Press Enter
If you're lucky, fixed errors should auto-magically disappear.
I had the same issue. In my case it was caused, because I had two files with the same name in one module:
index.ts
index.tsx.
I renamed one of them and the problem got fixed.
I faced the same issue, i tried above solution. None worked for me.
Then deleting build folder in my case - lib and rerun build cmd worked for me.
Use tsc --build --explainFiles to track down how your .d.ts is being included in your build!
e.g.
dist/index.d.ts
Imported via '..' from file 'mocks/mock-requests.ts'
In this case I should import something other than '..'...
See https://www.typescriptlang.org/tsconfig#explainFiles
I had the same issue and it's because of the exclude option. If you specify exclude option, you have to add the output directory also.
I had the exclude option like this "exclude": ["resources/js/**/*", "node_modules"] and the output directory set as outDir:"./build".
Adding build to the exclude option fixed the issue.
exclude:["resources/js/**/*", "node_modules", "build"]
Most likely, this happens when you try to run one project with two nodes.
For this hypothesis, you can test the count of processes on your computer named "node" after run build.
What I did to solve the problem:
Step 1.
Compare
node -v
and
nvm -ls
, the version in use.
In terminal set current node version:
nvm use {neededVersion}
In principle, delete unnecessary versions of the node in nvm (this will help your IDE to automatically determine the normal version of the node).
Step 2.
Determine the current node in your IDE. i.e. in WebStorm:
Preferencies->Languages & Frameworks -> Node.js and NPM | Typescript: Node interpreter - set needed version.
It seems like this issue was fixed for me by updating to Typescript 2.3.x
Also, using Visual Studio 2017 was a big improvement as well. I highly recommend that you make both of these updates though.
I solved this by removing "declaration": true from my tsconfig.json file. Though now I don't have declarations anymore so that didn't help.
In my case, I just changed "module": "commonjs" to "module": "esnext" and it fixed it.
When you are in a lerna package project or a monorepo project, it may work :
fist, your project look like this
packages\
core\
tsconfig.json
package.json
common\
tsconfig.json
package.json
tsconfig.base.json
your package.json
...
"main": "./lib/index.js",
"types": "./lib/index.d.ts",
"files": [
"lib"
],
...
your tsconfig.json
{
"extends": "../tsconfig.base.json",
"compilerOptions": {
"outDir": "./lib",
},
}
You will find that no matter how you change the tsconfig.json file, it doesn't work
So, this is my solution
delete you outDir:"lib" first, or use command rd lib /s /q , and run tsc, it will work
If you are working within a large code or monorepo sometimes just restarting your editor will suffice or if you are using vscode restarting the typescript language server.
As suggested in the GitHub issue, the best option to understand the problem is to launch the tsc command with the traceResolution flag
tsc --traceResolution
In my case due to developing a library and an app at the same time...
Moving a file, which has an import from the library, from the app to the library, resulted that the file that is now in the library would import stuff from its own dist folder..
Funny thing is.. this is actually refactoring at its best.. it kept the correct reference to the file :)
this config works for me
"allowJs": true
The allowJs option from another answer here got me thinking that perhaps my configuration didn't allow JavaScript files in the project.
So instead of doing all the outDir stuff that people recommend here, I renamed the problematic .js to .ts and that was it.
Granted, it was a boilerplate project and that file was the only JavaScript file in the whole (TypeScript) project.
set allowJS: true is not woI set outDir : true, it's work
Comparing this to Visual Studio Code all you need to do is allow source maps and VSCode will debug TypeScript however I can't achieve the same on WebStorm.
I can easily debug server side JavaScript in WebStorm but not TypeScript
For anyone else wrestling with debugging TypeScript in WebStorm/IDEA, I had similar frustrations as OP (possibly for different reason). My issue was simply that I didn't set the working directory to the dist folder in the node run configuration. I am running tests in Jest and assumed the working dir should be the root of my project. Set it to dist and debugging started working!
Further info...
Source .ts files in src
Typescript version: 2.0.3
File tsconfig.json:
{
"compilerOptions": {
"jsx": "react",
"module": "commonjs",
"noImplicitAny": false,
"outDir": "dist",
"preserveConstEnums": true,
"removeComments": true,
"sourceMap": true,
"target": "es6",
"moduleResolution": "node"
},
"exclude": [
"node_modules",
"dist"
]
}
Jest config (in package.json):
"jest": {
"scriptPreprocessor": "<rootDir>/node_modules/ts-jest/dist/preprocessor.js",
"testRegex": "(/__tests__/.*|\\.(test|spec))\\.(ts|tsx)$",
"moduleFileExtensions": [
"ts",
"tsx",
"js"
]
}
Run configuration...
Working directory: <project_root>/dist
Javascript file: ../node_modules/jest-cli/bin/jest.js
Application params: --runInBand
Hope it helps!
was trying to find a way to let Webstorm/Intellij to watch the TS file change and restart server in debug mode. Looks like ts-node-dev which IHMO is faster than nodemon in terms of live-reload because it shares Typescript compilation process between restarts.
npm i ts-node-dev --save-dev
Then in your Run/Debug Configuration, add a node.js config with below params:
JavaScript file ---> node_modules/ts-node-dev/lib/bin.js
Applicationi parameters ---> --respawn -- src/script/local.server.ts
Now save the config and run with Debug, you should be able to set break point as well as live reload server on any TS code change.
I wrapped up a small library for this if you happen to develop with aws lambda
https://github.com/vcfvct/ts-lambda-local-dev
Just want to add what worked for me with Webstorm 2021.1.1
I found the easiest way is to go to your package.json and right click the green triangle next to the npm script you want to run. Then select debug.
I am able to apply the breakpoints to my typescript code and it works perfectly. Coming from .Net where it was always pretty straight forward to debug, I am glad to see webstorm making it just as simple.
This is my npm script that I choose to debug.
"dev": "env-cmd -f ./config/dev.env concurrently -k -n COMPILER,NODEMON -c gray,blue \"tsc -w\" \"nodemon -w dist dist/index.js\"",
I'm using a specific version of node called ts-node.
First add in your package.json file:
"devDependencies": {
"ts-node": "8.1.0",
"typescript": "3.2.4"
},
Run npm install and the node_module/.bin/ directory will include the ts-node or ts-node.cmd required for Windows.
Obviously these versions will move. You may see inside the package.json of ts-node project which version of typescript they are using to be the closest as possible.
Then you can add breakpoints. The only downside I see is that you must define the Javascript file (which is a ts file) into the configuration, instead of just right-click + run.
If you have the xyz is not a function error, check that your tsconfig.json file doesn't have "noEmit": false,
For running WebStorm(2017.2.3) debugger around typescript sources I did:
Setup Node.js configuration:
Working directory: root/of/the/project (where located my package.json)
JavaScript file: dist/index.js
I am compiling my TypeScript with gulp-typescript, but more important the source-map files. So for compiling was used task like below:
const gulp = require('gulp');
const ts = require('gulp-typescript');
const sourcemaps = require('gulp-sourcemaps');
const merge = require('merge2');
const tsProject = ts.createProject('tsconfig.json', {
declaration: true,
typescript: require('typescript'),
});
gulp.task('default', () => {
const result = gulp.src('./app/**/*.ts')
.pipe(sourcemaps.init())
.pipe(sourcemaps.identityMap()) // optional
.pipe(tsProject());
return merge([
result.js
.pipe(sourcemaps.write('.', { includeContent: false, sourceRoot: '../app' }))
.pipe(gulp.dest('dist')),
result.dts
.pipe(gulp.dest('dist')),
]);
});
All source TS files located in './app' folder, all compiled files located in ./dist folder. Most important source-files option sourceRoot, wrong value not bring you to ts file.
By sourcemaps.write('.', { includeContent: false, sourceRoot: '../app' } I am writing my .map files beside .js files and make reference to app folder. I no need content in .map files because it's already there (app folder).
Thanks to #Ekaterina I was able to run Node debug with Typescript.
I'm toying around with an Angular 2 / Bootstrap 4 / Webpack project, just to see how the new stuff is lining up, and I'm trying to get debugging to work in IntelliJ IDEA 15 in Chrome with the JetBrains Chrome extension.
The problem is that any breakpoints I set in my TypeScript files are ignored. I'm using the built-in transpiler and leaving the JavaScript output files with the same name/location as the TypeScript files, so that my-app.ts is in the same folder as my-app.js and the associated my-app.js.map mapping file.
The odd thing is that if I set breakpoints in the generated JavaScript file, the IDE then breaks in the corresponding spot in the TypeScript file (even though it shows no breakpoint there). I can then step normally since the mapping seems to work.
The problem seems to be that setting a breakpoint in a .ts file doesn't set the needed breakpoint in the corresponding .js file.
Am I doing something wrong (I've never worked with TypeScript debugging before), or is this a bug in IDEA?
P.S. I get the same results whether doing remote JavaScript debugging or using local debugging through IDEA's built-in web server.
The trick was adding a reference to the Webpack internal URL to the debug config. The path to use for that Webpack URL will come from the scripts tab of the debugger when the application is running. You can also see it in Chrome's scripts tag just as easily, but I've included the view from IntelliJ IDEA here:
You can see that the . path in webpack:// corresponds to my project folder (as witnessed by the src path in it). That's what told me that I needed to use the . path for Webpack in the debug config. If your project lines up differently, you'll have to adjust accordingly.
As to why it is webpack:///. (with three slashes) instead of webpack://., that I can't answer. I saw that used in a JetBrains post and that's what led me to that solution of adding an additional forward slash.
Now you need to create your JavaScript debug configuration and set it up like the following:
Adjust your localhost URL and port, as well as your build path (__build__ in my case, maybe build or dist in yours).
Now that I have the debug configuration setup like the above, it works just fine.
I have successfully solved problem with debugging with webpack in Intellij/Webstorm based on this solution: How to debug angular 2 app using angular-cli webpack?. You have to map your main ui project directory and directory with .ts sources to remote url, exactly the same as in the solution upside.
My tsconfig.json:
{
"compilerOptions": {
"declaration": false,
"emitDecoratorMetadata": true,
"experimentalDecorators": true,
"lib": ["es6", "dom"],
"mapRoot": "./",
"module": "es6",
"moduleResolution": "node",
"noImplicitAny": false,
"outDir": "../resources/static/out-tsc",
"sourceMap": true,
"target": "es6",
"typeRoots": [
"../../../node_modules/#types"
]
}
}