Support module aliases

[SimeonC]

Support module aliases

[osdiab]

On a related note I am interested in trying this out on my project but alongside this particular problem (we use src/ as an alias for source code and keep every import absolute), in addition our structure is a monorepo via yarn workspaces - as such if I update file locations in one of the subpackages the other subpackages need to change their references to the shared repo as well. Probably a sufficiently separate issue to be its own ticket, but maybe if we could lock down some files/imports as the "public surface" of a package that might be useful too.

[AnatoleLucet]

@osdiab Hi, what are you using to alias src/? Typescript's aliases? We're trying to find every possible ways to tweak the js imports so Destiny would be able to resolve non-vanilla js imports (see #123) out of the box.

in addition our structure is a monorepo via yarn workspaces

This is already tracked in #70.

[osdiab]

My company basically relies on baseUrl to do it:

• for our api (packages/api/), we just set the baseUrl to . at the project root, and restrict the include field to ["src"]

{
  "extends": "./tsconfig.api.base.json",
  "compilerOptions": {
    // ...
    "baseUrl": "."
  },
  "references": [{ "path": "../common/" }],
  "include": ["src", "types"]
}

• for the api's tests (packages/api/__tests__/), it has its own tsconfig that extends the API's tsconfig, but includes the API itself as a project reference.

{
  "extends": "../tsconfig.json",
  "compilerOptions": {
    "noEmit": true,
    "types": ["jest", "node"]
  },
  "references": [{ "path": "../" }, { "path": "../../common" }],
  "include": ["./", "../types"]
}

• for our frontend web app (packages/website/), which uses create-react-app, we can only set baseUrl to src/ (thats a CRA limitation). So, we placed our code all in packages/website/src/@app and refer to web app code as @app/path/to/ReactComponent.

{
  "extends": "../tsconfig.base.json",
  "compilerOptions": {
    // ...
    "baseUrl": "./src",
  },
  "references": [{ "path": "../common" }],
  "include": ["src"]
}

For imports internal to these packages, that covers our use case! EDIT: for imports across subpackages, ie from API to common package, we rely on yarn workspaces, which routes imports to files via each subpackage's package.json name property - but I assume that might be harder to account for.

[AnatoleLucet]

Thank you! I've added Yarn workspaces and TSC's baseUrl to the list in #123.