I'm working with gremlin 3.5.2 and have the types dependency on:
"#types/gremlin": "^3.5.2"
But the tx() method isn't defined on the GraphTraversalSource.
I see the method is defined in the gremlin code, so I'm guessing this is only a lack of typescript type definition.
How do I get the updated types for this version?
Related
Context
Hi, I have a NodeJs+Ts+Architect setup for building and deploying lambda functions. Architect uses typescript plugin to compile typescript. I am trying to use Error class to throw errors.
However, Typescript is picking up Error type from
/Applications/Visual Studio Code.app/Contents/Resources/app/extensions/node_modules/typescript/lib/lib.es5.d.ts.
In the image below, please note the constructor signature only accepts message field. And the error interface does not have an options object either. Please
look at Browser Error Class or NodeJs Error Class to see the signatures.
Node Error has the following constructor signature and Error interface.
Problem
Getting TS Error for trying to use constructor signature of Node Error as Typescript is reading Error type from lib.es5.d.ts which accepts only 1 argument
Possible Solutions which I know
Declare global Error type ( Need help here. Since Architect is compiling TS using its plugin, I am not able to declare and override Error interface )
Use your own Error class
I hope the question made sense. Would appreciate if there is a nicer way to solve this, but I am not getting ample discussions on Architect+Ts+NodeJs.
The cause option was introduced in ES2022. You would need to use at least that version for your lib types.
Change the lib version in your tsconfig.json to:
"compilerOptions": { "lib": ["es2022"] }
I just started to learn typescript and just started converting my nodejs/express application to typescript.
I have successfully got all types for the library using npm i #types/some-lib
only library, I can't find was npm i #types/xss-clean
where to find this library
import xss from 'xss-clean' //getting type definition error
app.use(xss())
If the library does not have many TypeScript users, chances are that no published types exist. In that case you can add your own to whatever degree of detail you wish.
You can create a type definition file, e.g. xss-clean.d.ts:
declare module 'xss-clean'
{
const value: Function;
export default value;
}
[More on declaration files]
You can use this page to look up if a package has types or not. xss-clean does not seem to have any types yet, so you would have to declare them by yourself.
More info on that here.
I am having issues using the "entity" sub generator when attempting to update an existing entity.
When running the generator, at the end of the process, the following command is run:
yarn run cleanup && yarn run webpack:build:main
During this process I get these errors:
ERROR in [at-loader] dummy/path/car-delete-dialog.component.ts:58:23
TS2559: Type 'typeof CarDeleteDialogComponent' has no properties in common with type 'Component'.
ERROR in [at-loader] ./dummy/path/car-dialog.component.ts:147:27
TS2559: Type 'typeof CarDialogComponent' has no properties in common with type 'Component'.
ERROR in [at-loader] ./dummy/path/car-dialog.component.ts:150:27
TS2559: Type 'typeof CarDialogComponent' has no properties in common with type 'Component'.
Which can be fixed by changing:
his.modalRef = this.carPopupService
.open(CarDialogComponent, params['id']);
to:
this.modalRef = this.carPopupService
.open(CarDialogComponent as Component, params['id']);
These errors are just related to the entity that has been updated.
I understand why this has to be done but am unsure if this is something the generator etc should deal with.
JHipster version is 4.6.2 (I recently updated it) and I've not used the sub generator before as originally did an import from JDL studio.
Thanks in advance for any help you can give.
This has been resolved now.
I had a mismatch between the version the project was upgraded to (v4.6.2) and the global JHipster Generator (v4.6.1).
Updating the JHipster Generator version to v4.6.2 resolved the issues.
I have a node module A depending on another node module B, both written in Typescript. Module B returns Promises to A and have chosen bluebird as the Promise implementation. B of course have typings for bluebird.
However, if A doesn't have typings of bluebird (which it probably shouldn't in my case), I get errors like:
~/d/p/ensime-vscode ❯❯❯ tsc -p . ⏎ master ✭ ✱
node_modules/ensime-client/**/file-utils.d.ts(1,26):
error TS2307: Cannot find module 'bluebird'.
It took me a while to realize that this was due to me leaking the concrete Promise type of bluebird. Changing all the public return types to PromiseLike made the errors go away.
My question is, is there a way to detect these earlier on my independent module B? I recall sometimes getting errors when modules leaked types that wasn't public before, but in this case module B built just fine. It's all very blurry to me this thing since I'm very new to Typescript. I guess Typescript is a different beast compared to what I'm used to.
Also, isn't it possible for tsc to emit better error messages for these cases?
Small update:
When I'm "leaking" a type that is locally defined this is caught directly in B:
export interface CompletionsResponse extends Typehinted {
completions: [Completion]
}
interface Completion {
}
[ts]
Property 'completions' of exported interface has or is using private name 'Completion'.
interface Completion
I would like to be able to catch this kind of thing directly if I'm exposing something from a dependency like 'bluebird'.Promise as well. It was never my intention to expose 'bluebird' as a transitive dependency, and I honestly don't even know how to do that with typings? So as this builds just fine, what has happened is that 'bluebird' silently became a typings "peer dependency" in npm toungue.
If a package has a type dependency on another module, this dependency should be included in the package's typings.json, with typings install bluebird --save.
Your type declaration of module B should look something like this type declaration for redux-persist (but then inside your actual project). It depends on redux for several types. Therefore, there is a dependency listed in the typings.json.
Concerning typescript error messages, they're kind of a pain. ¯\_(ツ)_/¯
We have been building our application using groovy 2.3.6. Now because of some platform level issues we are advised to downgrade our groovy version to 2.2.1. I am facing no. of issues regarding this downgrade.
groovy is not able to infer the type of it variable in ver 2.2.1 so if i have code something like this
names.any { sliceName.endsWith(it) }
it gives me exception
[Static type checking] - Cannot find matching method java.lang.String#endsWith(java.lang.Object)
Secondly all the default method that i had used in collections no longer seem to exist
positions.any { it.primary }
groovy is unable to find the any method on list.
One way would be turn off static type checking, which will expose the code to a lot more runtime errors.
Is there any way to resolve these errors, without turning off static type checking. Also are these features only added in groovy 2.3.6 like default groovy methods and type inference for it variable
If you go back to an old version, old bugs will bite you.
Try giving the static compiler more of a hint
names.any { String it -> sliceName.endsWith(it) }