TypeScript path aliasses

[Pidz-b]

🚀 Feature Request

Affected Languages

• TypeScript or Javascript
• Python
• Java
• .NET (C#, F#, ...)

General Information

• JSII Version: AWS CDK 1.11.0 (build 4ed4d96)
• Platform: Linux 5.2.11-1-MANJARO

What is the problem?

When running cdk deploy or cdk synth, a path alias defined in in tsconfig.json is not resolved to the correct path.

I have all my CDK code in a folder named <project root>/infra/
In one of my files I import a custom file that abstracts our naming:

import { NameGen } from '@infra/lib/NameGen';

The tsconfig.json paths look like:

{
  "compilerOptions": {
    "paths": {
      "@infra/*": ["infra/*"],
      ....
}

When running CDK, the following error is thrown: Cannot find module '@infra/lib/NameGen'

---

Apparently JSII does not resolve the path aliasing of the tsconfig correctly?

[RomainMuller]

JSII does not allow you to override it's generated tsconfig.json; and thus currently setting paths is not supported.

Can you please laborite on what the use-case for path aliases is, so we can determine whether this is a feature that we should support?

[Pidz-b]

The use case is pretty code.

The only solution for this is to write the relative path out in full:

import { NameGen } from '../../../../infra/lib/NameGen';
import { MatchingStack } from '../../../../infra/MatchingStack';

In the code I generate for AWS lambda, I use path aliases to get rid of relative-path-hell:

require('@lib/bootstrap');
import FreelancerActivatedEventBody from '@event-handlers/FreelancerActivated/FreelancerActivatedEventBody';
import { SnsEventHandler } from '@lib/SnsEventHandler';

It makes the imports a lot more humanreadable and cleans up the code.

---

I hope clean code is a good enough reason to implement is, as clean code is a high priority for readability and maintainability IMO

[eladb]

We should stop including tsconfig.json files in our modules. It's not a good practice. I remember @rix0rrr said there was some reason related to doc generation??

[Pidz-b]

We should stop including tsconfig.json files in our modules. It's not a good practice. I remember @rix0rrr said there was some reason related to doc generation??

Is this related to my issue? Or related to the JSII compiler?

[Luca-Terrazzan]

This issue is still present in cdk as well (it uses JSII). In my case I would love to use ts paths in order to provide locators for my lambdas code.

[RomainMuller]

I'm contemplating whether we should allow user-controlled tsconfig.json (and restrict certain compiler options to maintain the needed compatibility -- for example, target <= "ES2018", module == "CommonJS", etc...). This would allow us not to have to worry about supporting all variants of inputs that tsc supports that users would want...

What do you guys think about this idea?