0

Right now, the Node tsc compiler looks at the tsconfig.jsonfile which looks something like this:

{
  "compilerOptions": {
    "target": "es5",
    "module": "system",
    "moduleResolution": "node",
    "sourceMap": true,
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "removeComments": false,
    "noImplicitAny": true,
    "suppressImplicitAnyIndexErrors": true
  }
}

Using the "module": "system" line, you can specify it to use SystemJS for managing modules. Is it possible to configure which configuration file SystemJS will use? I'd like to be able to specify custom defined modules so that Typescript won't complain about them, without having to create a separate .d.ts file for each one. It doesn't appear to be looking at either systemjs.config.js or system-config.js right now.

A. Duff
  • 4,097
  • 7
  • 38
  • 69
  • No, that's not possible, typescript doesn't take into account how the different module systems work, just how their modules are structured. But even if you could, that wouldn't help you the way you wanted. Knowing which external module are needed is different than knowing where to find their corresponding `.d.ts` files. But what's wrong with using [typings](https://github.com/typings/typings) or the [typescript 2 @types](https://blogs.msdn.microsoft.com/typescript/2016/06/15/the-future-of-declaration-files/)? Sounds exactly what you're looking for. – Nitzan Tomer Sep 03 '16 at 00:24
  • Issue is that when we deploy to production, I want to have several minified modules, grouped by the general purpose of their code, such as one for utilities (this is an Angular 2 project). I want developers to be able to change their code in one project locally and have the changes picked up automatically, but when we go to prod, I want our environment to just import everything from the module. But I don't want to have to define a typescript definition for every component we're creating. – A. Duff Sep 06 '16 at 14:57
  • I might have misunderstood what you're looking to do. Your problem is with your own modules, that are separated into different files and so you import them as much, and then in production you gather them together so that you need to import them differently? – Nitzan Tomer Sep 06 '16 at 23:08
  • Yes, that's correct. – A. Duff Sep 07 '16 at 14:05

1 Answers1

1

My comments on using the SystemJS config in the tsconfig.json file are still relevant as there's no option to do that.

But, now that I understand what you want, then it's possible to do with just typescript, if you structure your code the right way.
Let's assume the following module:

  • ModuleA
    • SubModuleOne
    • SubModuleTwo

In dev you want to import from ./ModuleA/SubModuleOne but in prod it should be from ./ModuleA as you compile all the inner modules into one file of the same name.

So how about always importing from ./ModuleA?
According to How TypeScript resolves modules:

an import statement like import { b } from "./moduleB" in /root/src/moduleA.ts would result in attempting the following locations for locating "./moduleB":

  1. /root/src/moduleB.ts
  2. /root/src/moduleB.tsx
  3. /root/src/moduleB.d.ts
  4. /root/src/moduleB/package.json (if it specifies a "typings" property)
  5. /root/src/moduleB/index.ts
  6. /root/src/moduleB/index.tsx
  7. /root/src/moduleB/index.d.ts

So if you have a ./ModuleA/index.d.ts (or .ts then you can there include of all the inner modules and then just importing from ./ModuleA will work both in dev and prod.
It's kind of like the python module with its __init__.py

Hope that will work out for you.

Nitzan Tomer
  • 155,636
  • 47
  • 315
  • 299