I'm working in a JS code base but I wanted to add declarations for some complex entities in the application. This is so I have them as auto-completable in my VS Code.
This works for dependencies that have TS declarations so I presume it can be done.
I tried the following in a d.ts file beside my .js file`
import "./useUserContext";
declare module "./useUserContext" {
interface User {
user: {
uid: string;
},
}
export default function useUserContext(): User;
}
There is sadly no possibility of converting this project to TS.
Related
I recently started using a Node library called bpmn-js (npmjs.com).
It is written in JavaScript, and I'd like to have typings. Thus, I've began reading about d.ts files.
I created this folder structure
webapp
#types
bpmn-js
index.d.ts
With a simple content
declare module 'bpmn-js' {
export class BpmnJS {
constructor();
}
}
But this doesn't seem to work.
"Before" typings, I was able to import the object I needed using
import BpmnJS from 'bpmn-js';
And I was able to instantiate it using
new BpmnJS();
How can I get the typings file to be recognized?
I'm using WebStorm 2019.1.*.
Pretty simple, I was missing export default, or better, the default part.
declare module 'bpmn-js' {
export default class BpmnJS {
constructor(param?: { container: string });
...
}
}
Now this works too
import BpmnJS from 'bpmn-js';
Let's assume you have a TypeScript project called "shubidu" and you are using Visual Code as IDE. "shubidu" well be a library, not an app.
Also, assume that your TypeScript project has two TypeScript files "core-stuff.ts" and "addon-stuff.ts".
// content of "core-stuff.ts"
export default function sayHello(name: string) {
console.log(`Hello, ${name}`)
}
-
// content of "addon-stuff.ts"
import sayHello from 'shubidu/core'
export default function helloWorld() {
sayHello('World')
}
Both files shall be transpiled to ES5 into two different modules "dist/shubidu-core.js" and "dist/shubidu-addon.js".
Later this "shubidu" library will be used by other projects like follows:
import sayHello from 'shubidu/core'
import helloWorld from 'shubidu/addon'
[...]
When you compile the "shubidu" project, there will be an error in file ""addon-stuff.ts" because module "shubidu/core" is unknown.
To fix this you have to modify file "tsconfig.json" like follows:
// content of tsconfig.json
{
[...]
"compilerOptions": {
[...]
"paths": {
"shubidu/core": "path/to/core-stuff.ts"
}
[...]
}
[...]
}
Compilation is working now. The open problem is that the Visual Code IDE itself still says (in file "addon-stuff.ts") that the module "shubidu/core" is unknown.
How can this be fixed???
How do you import an interface from another file?
If I use type I can do the following:
// branch.ts
export type Branch = {
colour: string
}
// tree.ts
import {Branch} from "./branch"
type Tree = {
branch: Branch[]
}
Whereas with interface it complains about it not being a namespace [ts] Cannot use namespace 'Branch' as a type.:
// branch.ts
export interface Branch {
colour: string
}
// tree.ts
import {Branch} from "./branch"
interface Tree {
branch: Branch[]
}
Project structure:
I cant publish the repo sorry, but here is the setup we have. We are using lerna so we are declaring modules in an index.d.ts file e.g. declare module "#shared/branch". It looks like tslint it can't find the interface export properly so complains. The code compiles and runs as expected though
I'm trying to use wasm-clingo in my TypeScript React project. I tried to write my own d.ts file for the project:
// wasm-clingo.d.ts
declare module 'wasm-clingo' {
export const Module: any;
}
and import like this:
import { Module } from 'wasm-clingo';
but when I console.log(Module) it says undefined. What did I do wrong?
Notes:
clingo.js is the main js file.
index.html and index_amd.html are two example pages
Solution:
I solved the problem like this:
// wasm-clingo.d.ts
declare module 'wasm-clingo' {
const Clingo: (Module: any) => Promise<any>;
namespace Clingo {}
export = Clingo;
}
and
import * as Clingo from 'wasm-clingo';
Here's the source for this solution
I know you found a solution acceptable to you; however, you don't really have any types here, you just have Module declared as any, which gives you no typescript benefits at all. In a similar situation I used #types/emscripten, which provides full type definitions for web assembly modules compiled using emscripten. You simply need to do:
npm install --save-dev #types/emscripten
then change your tsconfig.json types array to add an entry for emscripten.
After that you can just write Module.ccall(...) etc. If you like you could of course write const Clingo = Module and then make calls against that if you want a more descriptive name than Module (which is a terrible name!).
You're welcome ;)
I think the issue is that wasm-clingo exports the module itself but import { Module } from 'wasm-clingo' expects a property.
Try
import Clingo_ from 'wasm-clingo';
const Clingo: typeof Clingo_ = (Clingo_ as any).default || Clingo_;
I am writing private npm package to use internally, I also want to include some flowtypes in there that will be shared between internal projects and imported in following format import type {SomeType} from 'our-private-lib' But I am having trouble in doing so, what is the best approach to include flow types with npm package?
Currently I am transpiling all ES code with babel and then also using flow-copy-source to copy original files over along side transpiled files but with .js.flow extension, but then that means that the name of these files should be the same as the transpiled file?
For example if I have file in /super-schema/index.js with
export type SuperSchemaType = {
prop1: boolean,
prop2: string
}
const SuperSchema = {
prop1: true,
prop2: 'Hello'
}
module.exports = SuperSchema;
And package.json points to main file index.js which exports SuperSchema like so
module.exports = {
superSchema: require('./super-schema.js/index.js');
}
I then can import that like so
import {superSchema} from 'our-private-lib';
but what about flowtype? import type { SuperSchemaType } from 'our-private-lib'; Doesn't really work
Your general approach is correct (using flow-copy-source), but if you want to consume types out of the main entry point of your module, you need to export the types out one way or another. You can do that explicitly by doing something like
export type {
SuperSchemaType
} from './super-schema';
Or, if you're using babel 7, export type * might be useful for you
export type * from './super-schema';