Trying to compile a typescript project that uses lit-element and lit-html and has dependencies to other projects that use lit-html too gives me the error
.../lit-html/lib/parts").NodePart' is not assignable to type 'import(".../lit-html/lib/parts").NodePart'.
Types have separate declarations of a private property '__pendingValue'.
I'm using webpack#4.42.1 to try to compile the project.
Any ideas?
Add this to your tsconfig to force it to use a single source for lit-html:
"paths": {
...
"lit-html": ["node_modules/lit-html"],
"lit-html*": ["node_modules/lit-html/*"],
}
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 am using volar+vue2+ts+composiiton api. In SFC templates, for custom components, volar is able to perform type checks and give the following message when some errors encountered. It benefits me a lot.
I wonder if the type check is also applicable on components from third-party packages such as element-ui. When hovering over tags like el-*(components from element-ui), volar says it has the type of any and type check is not available. For jsx components, one can add types to the IntrinsicElements in shims-tsx.d.ts. But IntrinsicElements doesn't work for SFC templates. Is it possible to add types for third-party components?
import Vue, { VNode } from 'vue';
declare global {
namespace JSX {
interface Element extends VNode {}
interface ElementClass extends Vue {}
interface IntrinsicElements {
// JSX can add types here
'el-button': any;
[elem: string]: any;
}
}
}
As #Finn said, element-ui has added types. Unfortunately, even though El* classes are imported and registered via vue's components option, volar seems to be unable to do type checks. Here ElHeader is expected to have a prop named height of type string. But it is assigned a number without any error message
The following code snippet comes from the source of element-ui
export declare class ElHeader extends ElementUIComponent {
/** Height of the header */
height: string
}
Element-ui for vue2 has added components type declare in package,
so volar's type checks follows the package's types declaration.
I'm working on project, where we're using Stripe library for Node. We also want to use TypeScript on this project.
I've figured out that Stripe isn't providing official TypeScript definitions but I've found some community definitions #types/stripe on NPM. So I installed them and after a while I got an error:
Property 'sources' does not exist on type 'Stripe'.
Well there are missing some definitions, for example for this stripe.sources-related functionality.
I want to add missing definitions locally. So I need to extend this file:
#types/stripe/index.d.ts
I think that for the problem above I need:
to add property sources: Stripe.resources.Sources; to class Stripe,
to add class Sources to namespace resources,
to add missing function declarations to class Sources.
The problem is that I really don't know how. How should the .d.ts file with extensions look like? I've made many attempts according some examples and TypeScript docs but it always doesn't work. Do you have any idea?
I don't believe there's a way to augment the export-assigned Stripe class; the problem is similar to this open issue about augmenting a default-exported class. At this time, since you can't use augmentation, you'll have to fork the #types/stripe definitions for your project, and then you may as well make all the desired changes that way.
I think my colleague has found a solution that works for me. Here is how he made it:
import ST from 'stripe'
declare module 'stripe' {
namespace sources {
interface ISource extends IResourceObject {
...
}
interface ISourceCreationData {
...
}
}
namespace resources {
class Sources {
create(data: sources.ISourceCreationData): Promise<sources.ISource>;
retrieve(source: string, client_secret?: string): Promise<sources.ISource>;
}
}
class Stripe extends ST {
sources: ST.resources.Sources;
}
}
I have a groovy class "Utils.groovy" which contains the method "makeHttpCall()".
This is a summarized version of the method:
static String makeHTTPCall() {
...
request.setHeader(javax.ws.rs.core.HttpHeaders.AUTHORIZATION, authHeader)
...
}
The compiler complains:
Groovy:Apparent variable 'javax' was found in a static scope but
doesn't refer to a local variable, static field or class.
If I make the method non-static though, it will stop complaining;
String makeHTTPCall() {
...
request.setHeader(javax.ws.rs.core.HttpHeaders.AUTHORIZATION, authHeader)
...
}
this way it doesn't complain. Why does the compiler complain about this?
Note that the method runs with no problems; it is run as part of a Jenkins shared library.
Thanks!
EDIT: Using
import javax.ws.rs.core.HttpHeaders gives
Groovy:unable to resolve class javax.ws.rs.core.HttpHeaders
So that class is not resolvable by the compiler, but it is when run inside Jenkins.
You need to add the library that provides "javax.ws.rs.core.HttpHeaders" to your project's buildpath. Alternatively, you can use an #Grab to your class/script. This is probably not what you want in this case since Jenkins is providing that dependency at runtime.
I can't find TypeScript definition #type/{name} for one of my installed NodeJS packages, so I attempt to write a d.ts file for it, and put the file in {project root}\typings folder. This is how I do:
// My source code: index.ts
import Helper from 'node-helper-lib';
// My definition: \typings\node-helper-lib.d.ts
declare....(something else)
declare module 'node-helper-lib' {
class Helper { ... }
export = Helper;
}
However, Visual Studio Code keeps yielding this error and puts red line under declare module 'node-helper-lib':
[ts] Invalid module name in augmentation. Module 'node-helper-lib'
resolves to an untyped module at '{project
path}\node_modules\node-helper-lib\index.js', which cannot be
augmented.
Isn't it legit that because the library is untyped, so I should be allowed to add typing to it?
UPDATE:
I am using:
TypeScript: 2.1.4
Visual Studio Code: 1.9.1
Node JS: 6.9.4
Windows 10 x64
The actual solution is given in a comment by #Paleo in #hirikarate's answer:
Imports should be declared inside the module declaration.
Example:
declare module 'node-helper-lib' {
import * as SomeThirdParty from 'node-helper-lib';
interface Helper {
new(opt: SomeThirdParty.Options): SomeThirdParty.Type
}
export = Helper;
}
After some tries and errors, I found that augmentation means "declaring a module in the same file with other module declaration(s)".
Therefore if we want to write a definition file for an untyped 3rd-party JavaScript library, we must have ONLY ONE declare module 'lib-name' in that file, and 'lib-name' must exactly match the library name (can be found in its package.json, "name" property).
On the other hand, if a 3rd-party library already has definition file .d.ts included, and we want to extend its functionalities, then we can put the additional definition in another file that we create. This is called augmenting.
For example:
// These module declarations are in same file, given that each of them already has their own definition file.
declare module 'events' {
// Extended functionality
}
declare module 'querystring' {
// Extended functionality
}
declare module '...' { ... }
I leave my discovery here just in case somebody has same question. And please correct me if I missed something.
The issue for me was that I was trying to declare the module in a .ts file. I changed it to .d.ts and it all worked just fine.
I was getting that error message too. The issue for me was that I was trying to declare another module in an existing type definition file that had a module declaration in it. After I moved the new module declaration to a new file, the error went away.