I need to have some strongly-typed global variables.
As mentioned here: Extending TypeScript Global object in node.js, in order to add fields to the global variable I need to add a .d.ts file that extends the Global interface that's specified in node.d.ts.
Also, as Basarat mentioned:
Your file needs to be clean of any root level import or exports. That
would turn the file into a module and disconnect it from the global
type declaration namespace.
Now, I need to have fields on the Global interface whose types are custom interfaces that I created:
declare namespace NodeJS{
interface Global {
foo: Foo
bar: Bar
}
}
I'm extremely not willing to use the any type.
I can move/copy all the interface declarations to this declaration file, but it's a bad solution for me, since both Foo and Bar in turn, aggregate many fields of other interfaces, including third party interfaces like Moment etc.
I need a solution for this paradox
Here's an approach. I don't know if this is the 'correct' way of doing things, but it works for me with TypeScript 3.7.4.
Assuming your source files live in a folder src, create a new folder src/types and create a file global.d.ts in this folder.
Author your declarations using one of the following strategies:
If you need to import external types into your declaration file, use the following syntax:
import { Express } from 'express';
declare global {
namespace NodeJS {
interface Global {
__EXPRESS_APP__: Express;
}
}
}
If your declaration file does not contain any imports, the above will not work, and you'll need to use this syntax instead:
declare namespace NodeJS {
interface Global {
__CONNECTION_COUNT__: number;
}
}
Make sure your global.d.ts file (and any other files you might add to src/types) is picked up by the TypeScript compiler, by adding the following to your tsconfig.json file:
{
"paths": {
"*": ["node_modules/*", "src/types/*"]
}
}
Use the global variable as normal inside your code.
// Below, `app` will have the correct typings
const app = global.__EXPRESS_APP__;
I found this works.
Have one file that declares the property on the NodeJS.Global interface with the any type. This file has to be clean of imports or refrences.
node.d.ts
declare namespace NodeJS{
interface Global {
foo: any
}
}
Then in the second file you declare a global variable that has the correct type.
global.d.ts
import IFoo from '../foo'
declare global {
const foo:Ifoo
}
This worked for me (node v16.13.2)
In your root create file types/global.d.ts
declare global {
var __root: string
}
export {}
Note that __root declared with var keyword. It works with let and const too, but in this case __root will have any type. I don't know why;) If someone can explain this it will be great.
Configure your tsconfig.json
{
"compilerOptions": {
"typeRoots": [
"types"
],
}
}
Use declared variable in your code
// app.ts (entry point)
import path from 'path'
global.__root = path.join(__dirname)
// anyFileInProject.ts
console.log(__root) // will display root directory
Related
I have a /typings/$app.d.ts looks like this.
declare class App {
test: object
}
export const $app: App;
But in order to use the intellisense, I have to auto-import it and it will generate a line like this on the first line of my javascript code.
import { $app } from "../../typings/$app";
It will get in some error since it's a d.ts file.
Is there a way to make this $app.d.ts global like how the window does?
declare var something in .d.ts file top level scope is the keyword to expose global variable. Don't do export if you don't want to export anything.
declare class App {
test: object
}
declare var $app: App;
I would like to make a comment on #hackape 's answer and also recommend (if you haven't already) to add a tsconfig.json file to your project's root. Note that you can also add tsconfig if you don't want to use any typescript (only for intellisense).
You can have a minimal file like this:
{
"compilerOptions": {
"allowJs": true,
"typeRoots": ["./typings"],
"outFile": "./justANameToMakeTSHappy.js"
}
}
allowJs - so vscode would know to use the types also in the JS files.
typeRoots - let ts know where your types are.
outFile - so you don't get the error of 'can't overwrite file ****.js'
I am having issue with accessing namespace while importing it from a file that declares the namespace and a class with the same name. I can access the class but not the namespace.
From the docs, I thought importing from a library that exports merged namespace and class will give you properties from both declarations. But, I am getting properties from the class only.
Namespaces are flexible enough to also merge with other types of
declarations. To do so, the namespace declaration must follow the
declaration it will merge with. The resulting declaration has
properties of both declaration types. TypeScript uses this capability
to model some of the patterns in JavaScript as well as other
programming languages.
Here is my scenario,
Library file:
class GoldenLayout {
}
namespace GoldenLayout {
export interface Config {
}
}
In my project, I am trying to use Config interface. I am trying to use it this way,
import * as GoldenLayout from 'golden-layout';
const INITIAL_LAYOUT = GoldenLayout.Config = {
};
However, I get an error
Property 'Config' does not exist on type 'typeof GoldenLayout'.
I can access properties and method in the class GolderLayour, but I don't know how I can access the namespace.
For Reference, I am trying to use this library in my Angular 8 app.
I think your issue is that your not defining Config but rather double assigning. Try this:
const INITIAL_LAYOUT: GoldenLayout.Config = { };
I have a sample typescript objects as
declare const S3 = "https://s3.amazonaws.com/xxx/icons";
declare const SVG = "svg-file-icons";
declare interface MyIcons {
"image/jpeg": string;
"image/jpg": string;
}
export const FILE_ICONS_SVG: MyIcons = {
"image/jpeg": `${S3}/${SVG}/jpg.svg`,
"image/jpg": `${S3}/${SVG}/jpg.svg`
};
I am declaring this object in a share NPM Package to maintain consistency in all my projects. But TSC compilation gives me something like this.
"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
exports.FILE_ICONS_SVG = {
"image/jpeg": `${S3}/${SVG}/jpg.svg`,
"image/jpg": `${S3}/${SVG}/jpg.svg`
};
As it is evident that S3 and SVG are not defined in the compiled js file and thus gives errors on usage.
How can this be fixed??
Using declare does not really "declare" something.
declare is only used to tell the type-system that something with the declared name and type exists.
If you want to define a constant that should exist outside of the type-system, aka exist at runtime, you have to remove the declare keyword.
declare'd things do not have any impact on the runtime
Why does declare exist?
If you think about how the web works, you have a html file. In that html you can include scripts. Those scripts may be completely independent from one another, but also use stuff from other scripts.
So if you have one file that attaches something to the window for example in one file, and have another file that then uses this object, the typescript type-system has no way of knowing that that object exists, so you can tell the type-system of its existence by using declare
So it should be
const S3 = "https://s3.amazonaws.com/xxx/icons";
const SVG = "svg-file-icons";
I have an external JS library with a global parameter:
function Thing() { ... }
...
var thing = new Thing();
There is a TypeScript definition file, so in thing.d.ts:
declare var thing: ThingStatic;
export default thing;
export interface ThingStatic {
functionOnThing(): ThingFoo;
}
export interface ThingFoo {
... and so on
Then I import this into my own TS files with:
import thing from 'thing';
import {ThingFoo} from 'thing';
...
const x:ThingFoo = thing.functionOnThing();
The problem is that transpiles to:
const thing_1 = require("thing");
...
thing_1.default.functionOnThing();
Which throws an error. I've asked about that in another question, and the suggestion is to use:
import * as thing from 'thing';
That doesn't fix it - it gives me thing.default in TS but then that's undefined once transpiled to JS.
I think there's something wrong with thing.d.ts - there must be a way to define a typed global parameter that can be imported.
How should I write thing.d.ts so that it represents the JS correctly and doesn't transpile to include default or other properties not actually present?
If the only way to use that library is by accessing its globals (as opposed to importing it as node module or amd or umd module), then the easiest way to go is have a declaration file without any exports at top level. Just declaring a variable is enough. To use it, you have to include that declaration file when compiling your typescript code, either by adding it to files or include in tsconfig.json, or directly on command line. You also have to include the library with a <script> tag at runtime.
Example: thing.d.ts
declare var thing: ThingStatic;
declare interface ThingStatic {
functionOnThing(): ThingFoo;
}
declare interface ThingFoo {
}
test-thing.ts
const x:ThingFoo = thing.functionOnThing();
can be compiled together
./node_modules/.bin/tsc test-thing.ts thing.d.ts
the result in test-thing.js:
var x = thing.functionOnThing();
See also this question about ambient declarations.
Note: there are module loaders out there that allow using global libraries as if they were modules, so it's possible to use import statement instead of <script> tag, but how to configure these module loaders to do that is another, more complicated question.
Now I am sure the issue is because there is a d.ts file included which contains a module called "Shared", and a require statement which includes a variable of the same name if it is being used in a NodeJS environment.
// shared.d.ts
declare module Shared { ... }
// other_module.ts
/// <reference path="shared.d.ts"/>
if(require) { var Shared = require("shared"); }
export class Something {
public someVar = new Shared.SomethingElse("blah");
}
So when I compile other_module.ts (which is actually a lot of separate files), it tells me Shared is a duplicate identifier, which I can understand as TS thinks Shared is a module, but then is being told it is the return of require.
The problem here is that the output of modules need to be compatible with nodeJS's require system, so in this case when other_module is required it will be in its own scope and will not know about Shared.SomethingElse so the require is needed so the internal modules in other_module will be able to access the Shared library, but in the browser environment it would get Shared.SomethingElse via the global scope.
If I remove the reference then the file wont compile as it doesn't know about Shared, if I remove the require when the module is loaded into nodejs (var otherModule = require("other_module")) it will complain that it doesn't know about Shared. So is there a way to solve this?
First the error
Duplicate identifier because you have Shared in shared.d.ts + in other_module.ts.
FIX A, be all external
If you want to use amd / commonjs ie. external modules, you need to use import/require (not var/require like you are doing). Using an import creates a new variable declaration space and therefore you are no longer polluting the global namespace Shared from other_module.ts. In short :
// shared.d.ts
declare module Shared {
export function SomethingElse(arg:string):any;
}
declare module 'shared'{
export = Shared;
}
And a typesafe import:
// other_module.ts
/// <reference path="shared.d.ts"/>
import Shared = require("shared");
export class Something {
public someVar = new Shared.SomethingElse("blah");
}
FIX B, as you were, but you need to use a different name then
Inside other_module don't use the name Shared locally if local scope is global scope. I recommend you just use external everywhere and compile for node with commonjs and browser with amd as shown in fix A, but if you must here is a compile fixed other_module.ts.
// other_module.ts
/// <reference path="shared.d.ts"/>
var fooShared: typeof Shared;
if(require) { fooShared = require("shared"); }
else { fooShared = Shared; }
export class Something {
public someVar = new fooShared.SomethingElse("blah");
}