How to resolve relative paths with tsc in CodeBuild/Ubuntu (TS2307)?

Question

I fail to transpile my typescript files in AWS CodeBuild (Ubuntu image) with TS2307 error failing to resolve my own files.

Of course, I tried the exact same project locally. Invoking tsc which is reading my tsconfig.json file in the root of the project directory. Then I would run node ./dist/index.js to execute the app with node (and not ts-node ./src/index.ts). Works (the REST services provide json data).

In AWS CodeBuild the tsc fails.

These are my code lines which fail to be resolve relatively. Before there are absolute imports (e.g. import * as express from 'express') which all work fine.

Does someone have any clue why that does not resolve/transpile in AWS CodeBuild despite it is the same project files (all after a pull from github)? What flag am I missing?

I'm using Windows locally. And Ubuntu in CodeBuild.

import { TermEndpoints } from './endpoints/termEndpoints'
import { TranslationEndpoints } from './endpoints/translationEndpoints'
import { LanguageEndpoints } from './endpoints/LanguageEndpoints'
import { NavLangEndpoints} from './endpoints/navLangEndpoints'
import { InfoEndpoint } from './endpoints/infoEndpoint'

My tsconfig.json file is

{
    "compilerOptions": {
        "baseUrl": "./src/",
        "outDir": "./dist",
        "allowJs": true,
        "target": "es2017",        
        "module": "commonjs",
        "moduleResolution": "node",
        "sourceMap": false,
        "strict": false,
        "declaration": true,
        "experimentalDecorators": true,
        "importHelpers": true,
        "esModuleInterop": false,
        "resolveJsonModule": true,
        "removeComments": true,
        "types": ["node"],
        "typeRoots": [
            "node_modules/@types"
        ],
        "lib": [ "es2017", "dom" ]
    },
    "include": [
        "./src/**/*"
    ]
}

Log file from Code Build

[Container] 2020/05/11 10:06:10 Running command npm install typescript
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})

+ [email protected]
updated 1 package and audited 655 packages in 2.484s

found 0 vulnerabilities


[Container] 2020/05/11 10:06:13 Running command tsc --version
Version 3.8.3

[Container] 2020/05/11 10:06:13 Running command npm run build:acc

> [email protected] build:acc /codebuild/output/src400516343/src/github.com/svabra/semtranslatorapi
> tsc

src/ExpressServer.ts(11,31): error TS2307: Cannot find module './endpoints/termEndpoints'.
src/ExpressServer.ts(12,38): error TS2307: Cannot find module './endpoints/translationEndpoints'.
src/ExpressServer.ts(13,35): error TS2307: Cannot find module './endpoints/LanguageEndpoints'.
src/models/relation.ts(3,22): error TS2307: Cannot find module './Term'.
npm ERR! code ELIFECYCLE
npm ERR! errno 2
npm ERR! [email protected] build:acc: `tsc`
npm ERR! Exit status 2
npm ERR! 
npm ERR! Failed at the [email protected] build:acc script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /root/.npm/_logs/2020-05-11T10_06_18_948Z-debug.log

[Container] 2020/05/11 10:06:18 Command did not exit successfully npm run build:acc exit status 2
[Container] 2020/05/11 10:06:19 Phase complete: BUILD State: FAILED
[Container] 2020/05/11 10:06:19 Phase context status code: COMMAND_EXECUTION_ERROR Message: Error while executing command: npm run build:acc. Reason: exit status 2

Answer 1

Reason of Failure: a rookie mistake

I only respond for other Windows users to learn (it's a humilation towards myself in favour of rookies).

The error is due to case-insensitivity on windows. I never use upper case file names but for some reasons I once did for TermEndpoints.ts (and another). While importing the file with lower case termEndpoints.ts this worked of course in Windows 10. Anyhow, I saw it earlier and fixed it - but failed to upstream -u it (git push -u origin master). Thus I assumed it's fixed. It wasn't. Sorry guys for hanging in there.

Risk of case-insensitivity

DevOps-wise that could be a time-consuming penalty - or - if you miss out on end2end testing on a linux a dangerous scenario. Failing Acceptance Testing or Production release.

Eliminating the Risk: conduct case-sensitivity check

One is not an engineer if there is no lessons learned. Here is a safe-guard of a npm package for webpack, which enforces case-sensitive paths. Exactly what we need to prevent this risk. That can be applied for javascript as well as typescript (one should transpile typescript anyways into javascript before releaseing --> tsc -p .)

Another option is (as I did) to write your own script to test the references while you deploy. e.g. I'm hooking into the AWS Elastic Beanstalk .ebextensions. I invoke the command in a .config file within the .ebextensions folder. Of cource, there are dozens of other solutions how to invoke your verification script.

Mitigating the Risk: clone your production environment

If you feel that could never happen to you because you are developing on Linux or Max (nor to your successor), make sure that at latest your acceptance test environment is an clone of production. Because it's not just case-insensitivity of Windows that could get you. It's also case-preservation of a file system, unicode form preservation, and so on.

Cloning an environment is easy these days with Docker, AWS Beanstalk, AWS CloudFormation or TerraForm (Azure and Google have similiar services). The former ones can clone by a click, the latter two allow you to script your infrastructure and spin up a new instance for integration, acceptance testing, production, you name it. Ensure DevOps success.