Fix-tsc-es-imports NPM

fix-tsc-es-imports

fix-tsc-es-imports uses ShellJS sed to fix default extensionless typescript ECMAScript compiled code relative imports and exports, properly adding .js extensions.

Installing

npm install --save-dev fix-tsc-es-imports

Running

npx fix-tsc-es-imports

Or add it to your package.json module build script after your tsc run like this:

{
  "scripts": {
    "clean": "shx rm -rf lib",
    "tsc": "tsc --listEmittedFiles",
    "build": "npm run clean && npm run tsc && fix-tsc-es-imports -y -V"
  }
}

How it works

fix-tsc-es-imports looks for every .js file at the compileOptions.outDir folder found on the default tsconfig.json or another provided .json config file. Then it fixes all extensionless typescript relative imports and exports, adding .js extensions to them.

Usage

Usage:

fix_tsc_imports [-h|--help] [-y] [alternative_tsconfig.json]

  -h --help     usage info
  -y --yes      ignore confirmation and proceed straight away
  -V --verbose  verbose, outputs sed changed strings
  -d --dry      dry run, do not change anything and output sed changed strings (implied -V and -y)

An alternative tsconfig.json can be provided. It must have a .json extension. For example:

fix_tsc_imports -y ./dev/dev_tsconfig.json

See test/tsconfig_sample.json file.

Safe measures

fix-tsc-es-imports does a few safe checks to avoid touching the wrong code. It will check if outDir is a subfolder of the current folder and will not accept this folder names: src, node_modules, app.

Why do we need fix-tsc-es-imports?

Because when compiling ES6 modules with the current Typescript Compiler it generates .js files from .ts and .tsx files without properly fixing the imports expected from a ECMAScript module.

In face of that situation, our options are:

Forget about TSC and use Babel, losing type checking. Undesirable.
Keep TSC type checking and types generation and use Babel alongside to build our modules. Slower and mostly unnecessary.
Use Webpack, Babel and TSC altogether to produce a compiled packed module. We do not need to do that because modules will mostly certainly be included in another package that will be transpiled and packed down the development chain. So, also unnecessary.
Config Prettier to not complain about imports with extensions and manually review all our imports to have a fake .js extension while the source code has a .ts or .tsx extension. That does not seem to be the smartest option.
Use the .mjs and .cjs files extensions. Very overwhelming.
Use TSC to compile our Typescript code to ES6 or another module code, and generate maps and types, and got that module code properly imported in our other projects. That is mostly certain the best way to go.

So, this small script was built to add a .js extension to every extensionless Typescript generated import found in the compiled code. As current tsc compiler versions does not do that.