Should the index.ts be resolved by TypeScript as default module file?

Question

I am trying to get work the module resolution under typescript.

If I have:

/modulename/index.ts

should it be resolved by:

import * as modulename from "modulename"

?

I can't get it work. But

import * as modulename from "modulename/index"

works well.

Edit

as aluan-haddad recommended me it is neccessary to have the tsc configured properly.

This one worked for me:

{
   ...
   "baseUrl": ".",
   "module": "commonjs",
   "moduleResolution": "node",
   ...
}

Edit

Please note this configuration does not work when used with VS. If it is placed in external tsconfig file the compilation works well but language service can't handle it. If its is placed in msconfig (csporj) both, compiltion and language service fails.

Only the one solution I have found to be working for 100% is to create something like:

src
   node_modules
      module_being_currently_developed
         submodules

In this case the module resolution works properly.

Answer 1

It depends primarily on the --moduleResolution flag (compilerOptions.moduleResultion in tsconfig.json)

Automatic resolution of a directory to a file named index in that directory is a NodeJS convention. This convention propagated to client-side development but it remains a convention nevertheless. It is not part of the ECMAScript module specification or the AMD specification.

When specifying --moduleResolution node TypeScript will follow this convention.

Additionally, when the --module flag (compilerOptions.module in tsconfig.json) is set to commonjs this convention is applied automatically even in the absence of the --moduleResolution flag.

Note that the setting applies to both application code and to dependencies in directories such as node_modules, jspm_packages, and bower_components.

While it makes the most sense for CommonJS projects, setting --moduleResolution node can be advantageous in other module formats as it aids in the resolution of dependencies as well as avoids certain pitfalls that come with the alternative classic resolution mode.

Be advised however, that loaders such as RequireJS and SystemJS will not automatically pick up this convention in your app source code so use of explicit index files in module specifiers is still recommended when importing your own app code.

In spite of the CommonJS bent of the --moduleResolution node settings, I still prefer and recommend even though I do not use CommonJS, Webpack, or Browserify in the browser (when I can possibly avoid them).

My loader of choice is SystemJS, and my package manager of Choice is JSPM, but I still prefer to use the node resolution scheme because it makes importing dependencies easier, thanks in part to JSPM's auto configuring of the SystemJS loader.

Now, let us move on to --baseUrl as it applies to your scenario.

You are attempting to import a local module as

import * as modulename from "modulename";

and have set --module commonjs and --baseUrl / in an attempt an import the local module as if it were a third party package to prepare your codebase for its splitting off into a discrete package. This, I might add, is good planning, so :+10 for that!

However, if you plan to use a CommonJS modules (something I again advise against for browser only applications), you should most definitely set your "baseUrl" to "." rather than, "/". Even then, tools like the Native NodeJS require function have no support for the baseUrl concepts that originated in the browser tooling world. Webpack however, does support it.

At any rate, to load modules that are part of your own source code using a module specifier that is not a relative or absolute URL, I recommend the following regardless (be aware of loader requirements!):

1. Set "baseURl" to "."
2. Set "moduleResolution" to "node",
3. Set "module" explicitly to "commonjs", "system", or "amd" (I advise against "umd").
4. If not using "commonjs" under node, consider using "paths" as it allows for some very sophisticated restructuring.