Unexpected TS2306 (not a module) loading a relative path module via rootDirs.

[ShawnTalbert]

TypeScript Version: 2.0.2

I previously installed typescript declarations using
npm install @types/lodash

I have the following in my tsconfig.json

{
  "compilerOptions": {
    "module": "amd",
    "target": "es5",
    "noImplicitAny": false,
    "moduleResolution":"node", // using this lets us have rootDirs resolve stuff like moment with "./moment"
    "rootDirs": ["node_modules","./", "node_modules/@types"],
    "sourceMap": false,
    "newLine": "LF",
    "declaration": true,
    //"allowSyntheticDefaultImports": true
    //"emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "baseUrl": ".",
    "lib":["es5","es2015.promise"],
    "paths": {
      "N/*": [
        "node_modules/@hitc/netsuite-types/N/*"
      ]
    }
  },
  //"include": ["EC_Logger.ts", "DataAccess/*.ts"]
  "include": ["EC_Logger.ts"]
  //"exclude": ["node_modules", "test", "declarations"]
}

Then in EC_Logger.ts I have the following import

import * as _ from "./lodash"

results in

======== Type reference directive 'lodash' was successfully resolved to '/home/shawn/s/netsuite-fasttrack-toolkit-ss2/node_modules/@types/lodash/index.d.ts', primary: true. ========
EC_Logger.ts(8,20): error TS2306: File '/home/shawn/s/netsuite-fasttrack-toolkit-ss2/node_modules/@types/lodash/index.d.ts' is not a module.

If I change the import to be non relative, it resolves successfully and to the same physical file and compiles without error:

import * as _ from "lodash"

results in the following, and no compile error.

======== Type reference directive 'lodash' was successfully resolved to '/home/shawn/s/netsuite-fasttrack-toolkit-ss2/node_modules/@types/lodash/index.d.ts', primary: true. ========

Expected behavior:
The module should be recognized as a a valid module in both forms of import statements since it resolves to the same exact file?

Actual behavior:
'file is not a module' error when using relative path ./lodash, no error if using plain lodash

[mhegazy]

The issue here is that @types\lodash\index.d.ts is not a module. it is a global file that defines a module called "lodash" in the global scope.

it is a bit subtle. but import ... from "lodash" looks in the global scope for a module called "lodash" if it finds it it is fine. modules in the global scope can not have relative names, since there is nothing to be relative to in the global scope. import ... from "./lodash" is the module with file name ./lodash.d.ts or ./lodash/index.d.ts. since you are using rootDirs you have convinced the compiler that ./lodash and ./node_modules/@types/lodash are the same thing, so it tries to load /node_modules/@types/lodash/index.d.ts expecting it to be a module, but it is not. so the error.

this would have worked if lodash.d.ts was authored as a proper module (i.e. one top level import or export). this is an issue with the declaration file and not the compiler.

so, if i may ask, why are you importing lodash using a relative path?

[ShawnTalbert]

Understood.. I didn't realize global scope was quietly included with the non-relative style import. I do see that indeed lodash.d.ts doesn't contain a top level export anywhere.

I am using ./lodash because my target runtime environment (NetSuite) works well with relative paths.
They recently introduced some support for require.config() based somewhat on the requirejs standard. I can't find a way to make require.config() get emitted before the emitted amd define() code.
Even if I could use requirejs paths that would add more complexity (would have to manage paths in tsconfig.json AND in require.config.
This is a somewhat unique environment, in that individual code files (as AMD modules) get deployed and are the 'main' entrypoint for execution - which makes deployment very lightweight. Although each deployed script is an entrypoint/app on it's own, they still need to reference other code dependencies. In this scenario I think I would need a require.config block at the top of every single file.

The only workaround I've found is to avoid an import statement, add an ///<amd-dependency> to satisfy runtime and not import lodash at all. Is that the best I can do until the declaration is turned into an external module?