Is there a way I can import a module(?) (a set of functions) in typescript and be able to refer to these functions without the Module. prefix?
For example:
import * as Operations from './Operations';
Can I reference Operations.example() as example()? Essentially merging the 'namespace'?
You can do:
import { example } from './Operations';
This assumes you are exporting example from the file as a named export.
// ./Operations
export function example () {...}
Typescript Module Documentation
I was going through the codebase of an old project that uses Ember-CLI 1.13 and found something strange.
There are many helpers that are not directly used inside templates but are used in component js files by importing into them. One such example is
//..helpers/my-helper.js
export function func1 (param1, param2) {
//return something;
}
export function func2 (param1, param2) {
//return something;
}
export function func3 (param1, param2) {
//return something;
}
export default Ember.Helper.helper(func1);
export default Ember.Helper.helper(func2);
export default Ember.Helper.helper(func3);
And inside a component js file, I could see the above helpers being imported and used.
//../components/my-component.js
import Ember from "ember";
import { func1 } from '../helpers/my-helper';
import { func2 } from '../helpers/my-helper';
import { func3 } from '../helpers/my-helper';
I have few questions:
Shouldn't we create a utility instead of a helper in this case?
Is it ok to include many functions in a single helper file?
Are the imports inside the component file necessary?
Shouldn't we create a utility instead of a helper in this case?
Yes, but sometimes programmers are lazy or very restricted in time (even though moving function to utilities doesn't look like time-consuming task)
Is it ok to include many functions in a single helper file?
Yes, it is fine to have many functions in file and export them, but as far as I know, only default export will work in templates as helper. And I am 99% sure that not having default export will lead to build error.
Are the imports inside the component file necessary?
If these imports are used in component's code, then they are necessary. Otherwise, no.
Let's say I have a a.js file that contains:
export function a() {}
and I want it to import it from the file b.ts (in the same directory) like that:
import { a } from './a.js'
How can I tell TypeScript what the file a.js contains so that compilation of this import succeeds?
What is needed for this to work is typescript definition file named same as JavaScript file (a.d.ts in this case) that contains:
export function a();
It can also specify parameter types, additional exported functions and classes and must use export keyword to indicate what the JavaScript file actually exposes.
One other change is that this JavaScript module needs to be then imported in b.ts as:
import { a } from './a' // without .js
so it takes typescript definition file into account. It will still use implementation from a.js file. It works with webpack too.
If you don't want to describe what's inside a.js and have TypeScript just accept it you can create a.d.ts file like that:
declare var whateva:any;
export = whateva;
Then you can import it like this:
import * as ajs from './a'
and then refer to any function exposed by a.js in your TypeScript files like that:
ajs.a();
You can just simply use a statement:
declare var a:any;
(after the import) in this same file you are using the a (i this case in b.ts). Thanks to this the TS compiler will not complain. Also your IDE will not shown the errors.
I am trying to put together a module based architecture for my Meteor/Node application.
I have a client/main.js importing a imports/module1/index.js.
The imports/module1/index.js imports a imports/module1/api/api.js after it imports a component imports/module1/component/component1.js.
To sum it up, the simplified tree would look like this
.client/main.js
|_imports/module1/index.js
|_imports/module1/api/api.js
|_imports/module1/component/component1.js
The api.js file looks like that:
export default {
myFunction1 (arg1, arg2) {
// function stuff
},
myFunction2 (arg1, arg2) {
// function stuff
},
}
I expected to be able to call myFunction1(ar1,arg2) inside the imports/module1/component/component1.js but it doesn't work. What am I missing?
Currently you don't import api.js in your component1.js file so component1 has no access to any functions defined in the api.
Scope of a file doesn't "leak" so each file is completely separate in this matter. import in the main.js file doesn't automatically make all the imported modules available to its child modules – this wouldn't make sense. You have to import something in order to be able to use it.
I am using TypeScript 1.6 with ES6 modules syntax.
My files are:
test.ts:
module App {
export class SomeClass {
getName(): string {
return 'name';
}
}
}
main.ts:
import App from './test';
var a = new App.SomeClass();
When I am trying to compile the main.ts file I get this error:
Error TS2306: File 'test.ts' is not a module.
How can I accomplish that?
Extended - to provide more details based on some comments
The error
Error TS2306: File 'test.ts' is not a module.
Comes from the fact described here http://exploringjs.com/es6/ch_modules.html
17. Modules
This chapter explains how the built-in modules work in ECMAScript 6.
17.1 Overview
In ECMAScript 6, modules are stored in files. There is exactly one
module per file and one file per module. You have two ways of
exporting things from a module. These two ways can be mixed, but it is
usually better to use them separately.
17.1.1 Multiple named exports
There can be multiple named exports:
//------ lib.js ------
export const sqrt = Math.sqrt;
export function square(x) {
return x * x;
}
export function diag(x, y) {
return sqrt(square(x) + square(y));
}
...
17.1.2 Single default export
There can be a single default export. For example, a function:
//------ myFunc.js ------
export default function () { ··· } // no semicolon!
Based on the above we need the export, as a part of the test.js file. Let's adjust the content of it like this:
// test.js - exporting es6
export module App {
export class SomeClass {
getName(): string {
return 'name';
}
}
export class OtherClass {
getName(): string {
return 'name';
}
}
}
And now we can import it in these three ways:
import * as app1 from "./test";
import app2 = require("./test");
import {App} from "./test";
And we can consume imported stuff like this:
var a1: app1.App.SomeClass = new app1.App.SomeClass();
var a2: app1.App.OtherClass = new app1.App.OtherClass();
var b1: app2.App.SomeClass = new app2.App.SomeClass();
var b2: app2.App.OtherClass = new app2.App.OtherClass();
var c1: App.SomeClass = new App.SomeClass();
var c2: App.OtherClass = new App.OtherClass();
and call the method to see it in action:
console.log(a1.getName())
console.log(a2.getName())
console.log(b1.getName())
console.log(b2.getName())
console.log(c1.getName())
console.log(c2.getName())
Original part is trying to help to reduce the amount of complexity in usage of the namespace
Original part:
I would really strongly suggest to check this Q & A:
How do I use namespaces with TypeScript external modules?
Let me cite the first sentence:
Do not use "namespaces" in external modules.
Don't do this.
Seriously. Stop.
...
In this case, we just do not need module inside of test.ts. This could be the content of it adjusted test.ts:
export class SomeClass
{
getName(): string
{
return 'name';
}
}
Read more here
Export =
In the previous example, when we consumed each validator, each module only exported one value. In cases like this, it's cumbersome to work with these symbols through their qualified name when a single identifier would do just as well.
The export = syntax specifies a single object that is exported from the module. This can be a class, interface, module, function, or enum. When imported, the exported symbol is consumed directly and is not qualified by any name.
we can later consume it like this:
import App = require('./test');
var sc: App.SomeClass = new App.SomeClass();
sc.getName();
Read more here:
Optional Module Loading and Other Advanced Loading Scenarios
In some cases, you may want to only load a module under some conditions. In TypeScript, we can use the pattern shown below to implement this and other advanced loading scenarios to directly invoke the module loaders without losing type safety.
The compiler detects whether each module is used in the emitted JavaScript. For modules that are only used as part of the type system, no require calls are emitted. This culling of unused references is a good performance optimization, and also allows for optional loading of those modules.
The core idea of the pattern is that the import id = require('...') statement gives us access to the types exposed by the external module. The module loader is invoked (through require) dynamically, as shown in the if blocks below. This leverages the reference-culling optimization so that the module is only loaded when needed. For this pattern to work, it's important that the symbol defined via import is only used in type positions (i.e. never in a position that would be emitted into the JavaScript).
Above answers are correct. But just in case...
Got same error in VS Code. Had to re-save/recompile file that was throwing error.
How can I accomplish that?
Your example declares a TypeScript < 1.5 internal module, which is now called a namespace. The old module App {} syntax is now equivalent to namespace App {}. As a result, the following works:
// test.ts
export namespace App {
export class SomeClass {
getName(): string {
return 'name';
}
}
}
// main.ts
import { App } from './test';
var a = new App.SomeClass();
That being said...
Try to avoid exporting namespaces and instead export modules (which were previously called external modules). If needs be you can use a namespace on import with the namespace import pattern like this:
// test.ts
export class SomeClass {
getName(): string {
return 'name';
}
}
// main.ts
import * as App from './test'; // namespace import pattern
var a = new App.SomeClass();
In addition to A. Tim's answer there are times when even that doesn't work, so you need to:
Rewrite the import string, using the intellisense. Sometimes this fixes the issue
Restart VS Code
I had this issue and I had forgotten to export the Class.
In addition to Tim's answer, this issue occurred for me when I was splitting up a refactoring a file, splitting it up into their own files.
VSCode, for some reason, indented parts of my [class] code, which caused this issue. This was hard to notice at first, but after I realised the code was indented, I formatted the code and the issue disappeared.
for example, everything after the first line of the Class definition was auto-indented during the paste.
export class MyClass extends Something<string> {
public blah: string = null;
constructor() { ... }
}
Just in case this may works for you as it did form me, i had this files
//server.ts
class Server{
...
}
exports.Server = Server
//app.ts
import {Server} from './server.ts'
And this actually raised an error but i changed server.ts to
//server.ts
export class Server{
...
}
and it worked 😎👌
Note: i am using this config
"target": "esnext",
"module": "commonjs",
I faced the same issue in a module that has no exports. I used it for side-effects only. This is what the TypeScript docs say about importing side-effects modules:
Though not recommended practice, some modules set up some global state that can be used by other modules. These modules may not have any exports, or the consumer is not interested in any of their exports. To import these modules, use:
import "./my-module.js";
In that situation, you can fix the "File is not a module" error by simply exporting an empty object:
// side-effects stuff
export default {};
I faced the same issue ("File is not a module error") for import js in vue component
import handleClientLoad from "../../../public/js/calendar.js"
I do this and solve it
// #ts-ignore
import handleClientLoad from "../../../public/js/calendar.js"
The file needs to add Component from core hence add the following import to the top
import { Component } from '#angular/core';