On version 2.1.0 - transpiling to AMD, in the browser I have this:
import { createStore } from 'redux'
var store = createStore(() => {})
const x = module.id;
which transpiles to:
define(["require", "exports", "redux"], function (require, exports, redux_1) {
"use strict";
var store = redux_1.createStore(function () { });
var x = module.id;
});
however, I am looking to grab a hold of the module object from a RequireJS module. So what I am looking for is something like this instead:
define(["require", "exports", "module", "redux"], function (require, exports, module, redux_1) {
"use strict";
var store = redux_1.createStore(function () { });
var x = module.id;
});
am I doing something wrong? Is this possible?
Couldn't you just do import module = require('module') or use the AMD dependency directive (https://www.typescriptlang.org/docs/handbook/triple-slash-directives.html)?
Let me try that, not sure
@blakeembrey thanks import module = require('module') seemed to do the trick, will have to look into the triple slash directive thing too
Usually, the code I write in TypeScript is unaffected by whatever setting I have for module in my compiler configuration. I can switch from amd to commonjs whenever I want to. I can publish a library that uses amd to produce a bundle and let consumers take the same TypeScript code and compile it with commonjs, or the other way around. The TypeScript code does not change either way.
The problem with import module = require('module') is that once I add this to my code to make it work with amd, it ceases to work with commonjs, and all of the benefits above go out the window. When SystemJS sees the require('module') call in a CommonJS module, it takes it at face value and tries to fetch a module named module. The Node.js loader will load a platform module named module that is only tangentially related to the module object that is created in the scope of a module.
If the compiler emitted amd code that did this:
define(["require", "exports", "module", ...], function (require, exports, module, ...) {
});
Then module.id could be available without any need to change the TypeScript code.
/// <amd-dependency /> is ignored if the module type is commonjs so it works with both output types. However, the documentation says it is deprecated. "Deprecated" to me means "don't use it because we're going to remove it". So it is not a long term solution.
+1
Is there a solution? For now I'm using the triple comment syntax.
/// <amd-dependency path="module" name="module"/>
Most helpful comment
Usually, the code I write in TypeScript is unaffected by whatever setting I have for
modulein my compiler configuration. I can switch fromamdtocommonjswhenever I want to. I can publish a library that usesamdto produce a bundle and let consumers take the same TypeScript code and compile it withcommonjs, or the other way around. The TypeScript code does not change either way.The problem with
import module = require('module')is that once I add this to my code to make it work withamd, it ceases to work withcommonjs, and all of the benefits above go out the window. When SystemJS sees therequire('module')call in a CommonJS module, it takes it at face value and tries to fetch a module namedmodule. The Node.js loader will load a platform module namedmodulethat is only tangentially related to themoduleobject that is created in the scope of a module.If the compiler emitted
amdcode that did this:Then
module.idcould be available without any need to change the TypeScript code./// <amd-dependency />is ignored if the module type iscommonjsso it works with both output types. However, the documentation says it is deprecated. "Deprecated" to me means "don't use it because we're going to remove it". So it is not a long term solution.