Add support of path section of tsconfig for serverless.ts

[CorentinDoue]

Use case description

Using a serverless.ts config in a typescript project with tsconfig paths, the paths are not resolved by serverless framework during the requirement of serverless.ts

// tsconfig.json
{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@libs/*": ["libs/*"],
      "@resources/*": ["resources/*"]
    }
  }
}

// serverless.ts
import { Table } from "@resources/dynamodb";

module.exports = {
   service: "myServiceName",
   resources: { Resources: { Table }, },
}

=>

Serverless Error ---------------------------------------                                                                                                                                                         
                                                                                                                                                                                                                   
  Cannot load "serverless.ts": Initialization error: Error: Cannot find module '@resources/dynamodb'                                                                                                               

Proposed solution

According to ts-node documentation (currently used for transpilling serverless.ts), it is required to use the package tsconfig-paths to resolve the paths option of ts config.

IMHO, we should not require tsconfig-paths to load serverless.ts but we could first try to load it using require("ts-node").register({ require: ["tsconfig-paths/register"] }); and fallback to the original code if not found: https://github.com/serverless/serverless/blob/5fa51dc53d039814aef80dd2a8c8069015215696/lib/configuration/read.js#L105

WDYT ?

[nhammond101]

I came to the same conclusion - i opened a PR (serverless/serverless#8931) but it does impact the core serverless library, and i'm trying to write tests for handling when tsconfig-paths is and isn't available to be used

#28

[fredericbarthelet]

Thanks @CorentinDoue for reporting this isssue.
I'm closing this in favor of #28. Let's continue the discussion over there :)