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.
Related
Partially solved:
There is an old issue on github where this problem is described a bit. When you declare a module in a global scope, it rewrites the whole exported module's types. When you declare a module inside a module, it merges. Why? I have no idea
https://github.com/microsoft/TypeScript/issues/17736#issuecomment-344353174
I want to extend third party module's type by interface merging. Everything works fine, but when I comment
export {}; in types.d.ts I encounter the following error:
This expression is not callable. Type 'typeof import("koa-session")'
has no call signatures
Could you explain why it happens?
You can check the working code here:
https://codesandbox.io/s/typescript-node-nocfq?file=/src/types.d.ts
A similar problem has been addressed on TypeScript github. Unfortunately I am now aware of any other documentation page that would describe it.
Commenting out the export {} turns the types.d.ts file from a module into a script. From TypeScript handbook:
In TypeScript, just as in ECMAScript 2015, any file containing a top-level import or export is considered a module. Conversely, a file without any top-level import or export declarations is treated as a script whose contents are available in the global scope (and therefore to modules as well).
Since the file without export statement (and without import statement) is not a module but rather a script it has no information about any modules and will indeed disregard the fact that there is an existing definition for "koa-session".
You can try this in your sandbox - adding any top-level import or export in types.d.ts (it can be completely unused) will fix the This expression is not callable error.
You need to import the interface if you want to enhance it and do interface merging. What you're doing is rewriting it altogether.
import Session from "koa-session";
declare module "koa-session" {
interface Session {
user: {
id: number;
username: string;
};
}
}
Just do this and you will enhance the interface just as you want.
How can I instantiate a class (with, say, a known empty constructor), for example:
at api/EmptyClass1.ts, I have:
export default class EmptyClass1 {
}
and, at api/EmptyClass2.ts, I have:
export default class EmptyClass2 {
}
I want this function:
function(filepath:string):any{
return Object.fromFile(filepath); //this line is mock code
}
to return a new instance of either EmptyClass1 or EmptyClass2, if the parameter filepath:string is "api/EmptyClass1.ts" or "api/EmptyClass2.ts", respectively.
The files defining the classes may not be known at the time the function is written may include any number of files. Consequently, using the import statement for each class, then using a switch, or if-then statements is not an acceptable solution.
The .ts files defining the classes are transcoded to javascript and reside in the application .build folder as .js files.
I am using typescript on node.js (recent versions).
Use require instead, and your problem will be solved. If the file may not exist, you can use optional-require if you want to have a fallback without using try/catch.
function fromFile(filepath:string):any{
// return Object.fromFile(filepath); //this line is mock code
return require(filepath);
}
Or just call require directly instead of wrapping it in another function.
Also check:
nodejs require inside TypeScript file
When I try to import node.js module in TypeScript like this:
import co = require('co');
import co from 'co';
without providing type definitions, both lines reports same error:
error TS2307: Cannot find module 'co'.
How to import it correctly?
The trick is to use purely JavaScript notation:
const co = require('co');
Your options are to either import it outside TypeScript's module system (by calling a module API like RequireJS or Node directly by hand) so that it doesn't try to validate it, or to add a type definition so that you can use the module system and have it validate correctly. You can stub the type definition though, so this can be very low effort.
Using Node (CommonJS) imports directly:
// Note there's no 'import' statement here.
var loadedModule: any = require('module-name');
// Now use your module however you'd like.
Using RequireJS directly:
define(["module-name"], function (loadedModule: any) {
// Use loadedModule however you'd like
});
Be aware that in either of these cases this may mix weirdly with using real normal TypeScript module imports in the same file (you can end up with two layers of module definition, especially on the RequireJS side, as TypeScript tries to manage modules you're also managing by hand). I'd recommend either using just this approach, or using real type definitions.
Stubbing type definitions:
Getting proper type definitions would be best, and if those are available or you have time to write them yourself you should definitely should.
If not though, you can just give your whole module the any type, and put your module into the module system without having to actually type it:
declare module 'module-name' {
export = <any> {};
}
This should allow you to import module-name and have TypeScript know what you're talking about. You'll still need to ensure that importing module-name does actually load it successfully at runtime with whatever module system you're using, or it will compile but then fail to actually run.
I got an error when I used the "Stubbing type definitions" approach in Tim Perry's answer: error TS2497: Module ''module-name'' resolves to a non-module entity and cannot be imported using this construct.
The solution was to rework the stub .d.ts file slightly:
declare module 'module-name' {
const x: any;
export = x;
}
And then you can import via:
import * as moduleName from 'module-name';
Creating your own stub file lowers the barrier to writing out real declarations as you need them.
Just import the module the following way:
import 'co';
I'm trying to write an ambient module in node.js using the Visual Studio developer tools.
The module looks like this
module "Module" {
export class Class {
first = "First";
second = "Second";
}
}
I think attempt to use this in another file:
var m = require("Module");
var c = new m.Class();
The typing on the require statement is fine, but this gives a compiler error, saying "Only ambient modules can use quoted names".
How then am I supposed to write my TypeScript modules such that they can be imported into other project files, and the import is strongly typed?
Use declare.
declare module "Module" ...
I'm writing a web app using TypeScript, Backbone, and Mustache. I want to use Requirejs for dependency loading.
I'm also using the Web Essentials visual studio plugin for TypeScript with the AMD compilation option turned on. For those that are not familiar with this, it will wrap your type script file in an AMD module if you import external modules.
For example:
In type script I import the following modules in type definition files.
export import Backbone = module("Backbone");
import mainTemplate = module("MainTemplate");
The output is something like:
define(["require", "exports", "Backbone", "MainTemplate"], function(require, exports, __Backbone__, __mainTemplate__) {
//...code goes here ...
});
For the template, I've declared the following in a type definition file:
declare module "MainTemplate" { }
In order to support requirejs plugins, you need to declare your module as:
declare module "text!MainTemplate.html" { }
I'd like to keep the module name free of plugins and file extensions. This would leave me with some flexibility in the future.
I have the following mapping in require.
require.config({
map: {
"MyModule": {
"MainTemplate": "text!MainTemplate.html"
}
}
}
This successfully invokes the text plugin however, the plugin loads the wrong url. Sifting through the source code for the text plugin, I found that the following code is the culprit.
load: function (name, req, onLoad, config) {
...
url = req.toUrl(nonStripName),
//returns "scripts/**text!**MainTemplate.html**.html**"
...
}
If I name the module, 'MainTemplate.html' it works fine but I'd like to keep the extension out of the module name.
I've modified the text plugin with a simple regex replacement to strip out the plugin reference and the duplicate extension.
Is there a better way to handle this?
Ran into similar issue. Solved finally. See TypeScript: compiling removes unreferenced imports
/// <amd-dependency path="text!templates/application.htm" />
var applicationTemplate = require('text!templates/application.htm');
For Typescript 1.0 this works for me.
First I created a .d.ts file which stores all module declarations for each text template.
//workaround for typescript's lack of support for requirejs text template notation
//remember that a reference to the import variable has to be found in the class, otherwise typescript ignores the import
declare module "text!views/details/details.html" {
var text: string;
export = text;
}
declare module "text!views/layout/layout.html" {
var text: string;
export = text;
}
declare module "text!views/home/home.html" {
var text: string;
export = text;
}
then to refer to the text template I add these lines on top of the class/module.
/// <reference path="../texttemplate.d.ts"/>
import detailsTemplate = require('text!views/details/details.html');
The reference line is not actually needed, since the .d.ts file is picked up globally. But I added it as a reminder of the workaround. It also makes it easy to ctrl+click to go the d.ts. file.
There is a slightly nicer way to do this (I'm using typescript 2.0)
Referenced here: https://www.typescriptlang.org/docs/handbook/triple-slash-directives.html
This code expects that your requirejs configuration and plugins are set up correctly:
/// <amd-dependency path="text!./about.html" name="template"/>
declare let template: string;
This helped me a lot to migrate lagacy code to typescript.
Since TypeScript 0.9.0 I think you need to do the following:
/// <amd-dependency path="text!templates/application.htm" />
declare var require:(moduleId:string) => any;
var applicationTemplate:string = require("text!templates/application.htm");
Check out more at http://www.codebelt.com/typescript/typescript-amd-with-requirejs-tutorial/
We are using Backbone and require.js for our TypeScript applications.
We don't use the
import backbone = module("Backbone")
syntax, but rather use a
/// <reference path="../../modules/Backbone.d.ts" />
reference, and then a BootStrapper.
This way, the 'text!htmlfile.html' syntax works perfectly with require.js.
I've put together a blog on using require.js with TypeScript and AMD:
http://blorkfish.wordpress.com/2012/10/23/typescript-organizing-your-code-with-amd-modules-and-require-js/