Im not actually including these types in from anywhere, ive no idea what package is adding them but its causing errors in my app.
@types/readable-stream package and had problems.node_modules/@types/readable-stream/index.d.ts(138,18): error TS2749: 'StringDecoder' refers to a value, but is being used as a type here.
Sorry to hear this, other users have not reported this problem so it sounds like a versioning issue.
There's a few possibilities, first if you have @types/node as a dependency in your package.json could you check this PR https://github.com/DefinitelyTyped/DefinitelyTyped/pull/37869#issuecomment-524529255 for a possible solution. If you are using @types/node v10 in your package.json dependencies, you might need to update to v12 (depending on which version of TypeScript you're using).
If that fix doesn't help you, could you provide the TypeScript version you are using and the list of"dependencies" and "devDependencies" from your project's package.json file. We can use the list of dependencies to track down what's adding readable-stream to your project.
Alternative - if you do not wish to post your package.json dependencies.
./node_modules/@types/readable-stream/package.json in a text editor."_where" property and that "_where" path will be the package that imported readable-stream."_where" path, navigate to it in node_modules and open its package.json file and check the "_where" property.And with that info, you can figure out what's importing readable-stream and we can trouble shoot further.
I got the same problem. Error when using "tsc" command. It is a sample app, very simple and with only two dependencies on the package.
Error:
node_modules/@types/readable-stream/index.d.ts:138:18 - error TS2749: 'StringDecoder' refers to a value, but is being used as a type here.
138 decoder: StringDecoder | null;
~~~~~~~~~~~~~
Found 1 error.
Versions:
$ node --version
v13.7.0
$ npm --version
6.13.7
$ tsc --version
Version 3.7.5
package.json
{
"name": "vesperapp",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1",
"start": "tsc && node ./build/index.js"
},
"author": "",
"license": "ISC",
"dependencies": {
"mssql": "^6.1.0",
"vesper": "^0.1.9"
}
}
tsconfig.json
{
"compilerOptions": {
"lib": [
"es5",
"es6",
"es7",
"esnext"
],
"target": "esnext",
"module": "commonjs",
"moduleResolution": "node",
"outDir": "./build",
"emitDecoratorMetadata": true,
"experimentalDecorators": true,
"sourceMap": true
}
}
I've deleted the package-lock.json file and the node_modules folder and entered the command npm install again. This worked for me. I can assure you that this is not an issue of this node module, maybe its an npm problem, not sure.
node_modules/@types/readable-stream/index.d.ts:95:17 - error TS2339: Property 'asyncIterator' does not exist on type 'SymbolConstructor'.
95 [Symbol.asyncIterator](): AsyncIterableIterator<any>;
~~~~~~~~~~~~~
node_modules/@types/readable-stream/index.d.ts:95:35 - error TS2304: Cannot find name 'AsyncIterableIterator'.
95 [Symbol.asyncIterator](): AsyncIterableIterator<any>;
~~~~~~~~~~~~~~~~~~~~~
node_modules/@types/readable-stream/index.d.ts:138:18 - error TS2749: 'StringDecoder' refers to a value, but is being used as a type here.
138 decoder: StringDecoder | null;
~~~~~~~~~~~~~
Found 3 errors.
I got this with @types/readable-stream ver 2.3.5. It came along when my project needed mssql and it requires tedious, which in turn depends on readable-stream.
I'll try to clean the package-lock but I doubt it helps since the same error came from CI which shouldn't cache the lockfile...
I got this with @types/readable-stream ver 2.3.5. It came along when my project needed mssql and it requires tedious, which in turn depends on readable-stream.
I'll try to clean the package-lock but I doubt it helps since the same error came from CI which shouldn't cache the lockfile...
I created a clean project with just typescript, mssql and types/mssql dependencies, and tsc seems to run just fine. The lock files show same versions. I have to dig deeper, maybe there's different typescript version or something...
Although I thought I was using the same ts config, the problem lies in compiler target version. es2017 has the problem, but es2018 doesn't.
As an experiment, I changed the line in question from:
decoder: StringDecoder | null;
to:
decoder: (typeof StringDecoder) | null;
This seems to have eliminated the error we were observing within the knex CI, at least.
I'll submit a PR for this as soon as I can. I'm at a coffee shop right now, and the internet appears to be too slow to clone this repo.
On a (probably?) related note: it looks like there is a "string_decoder" library that is possibly a polyfill for older versions of node:
https://www.npmjs.com/package/string_decoder
Additionally, it looks like this library does not provide any Typescript definitions.
In the knex case, it looks like this "string_decoder" polyfill is being pulled in from a few places. So, perhaps this is confusing Typescript? (ie: its resolving the reference to the polyfill instead of Node's implementation, which is then causing Typescript to get angry?)
So yeah: my observation about the "string_decoder" library missing type definitions seems to be the underlying issue. On my local machine, I:
(typeof StringDecoder) work-around that I mentioned earlier./node_modules/@types/string_decoder/index.d.ts that contained the following:declare class StringDecoder {
constructor(encoding: string);
}
(In other words: I created a non-published type definition for the "string_decoder" library)
Once again, this seems to have eliminated the issue we were observing when running the knex CI.
So, if I have time this afternoon, I'll take a stab at creating an official type definition for the "string_decoder" library. But, I won't be too terribly upset if somebody else beats me to it. 馃槄
One more quick update on this front: I noticed that I omitted the export keyword on the previous snippet. When I introduced it, the knex CI started failing again.
So... I'm gonna do a bit more investigation to make sure I understand how to write index.d.ts files by hand properly. In the meantime, I'll also be interested to hear if anybody else has success w/ this line of experimentation.
As @TeamworkGuy2 mentioned above, this appears to be related to v10 of @types/node . Updating to 13.7.7 or newer seems do the trick:
https://github.com/DefinitelyTyped/DefinitelyTyped/issues/42275#issuecomment-585502028
Cracking open the source code for @types/node , it looks like the "string_decoder" module used to be declared as:
declare module "string_decoder" {
interface NodeStringDecoder {
write(buffer: Buffer): string;
end(buffer?: Buffer): string;
}
const StringDecoder: {
new(encoding?: string): NodeStringDecoder;
};
}
Notice that StringDecoder is declared as a const (rather than an interface or a class). This seems to be throwing Typescript off. (I'm guessing that the syntax around the new keyword is no longer supported. Consequently, Typescript thinks that StringDecoder is an Object instead of a function / class. But, I haven't actually confirmed this yet).
For comparison, the latest version of @types/node declares the module as:
declare module "string_decoder" {
class StringDecoder {
constructor(encoding?: string);
write(buffer: Buffer): string;
end(buffer?: Buffer): string;
}
}
This should establish both the "type" and "value" aspects of StringDecoder.
Most helpful comment
As @TeamworkGuy2 mentioned above, this appears to be related to
v10of@types/node. Updating to13.7.7or newer seems do the trick:https://github.com/DefinitelyTyped/DefinitelyTyped/issues/42275#issuecomment-585502028
Cracking open the source code for
@types/node, it looks like the"string_decoder"module used to be declared as:Notice that
StringDecoderis declared as aconst(rather than aninterfaceor aclass). This seems to be throwing Typescript off. (I'm guessing that the syntax around thenewkeyword is no longer supported. Consequently, Typescript thinks thatStringDecoderis an Object instead of a function / class. But, I haven't actually confirmed this yet).For comparison, the latest version of
@types/nodedeclares the module as:This should establish both the "type" and "value" aspects of
StringDecoder.