Support module aliases

[SimeonC]

In our projects we make heavy use of flow's module.name_mapper and also babel's module alias configuration. This lets us make imports like this import SideNav from 'modules/SideNav';.

Then in .flowconfig we have module.name_mapper='^modules/\(.*\)$' -> '<PROJECT_ROOT>/src/modules/\1'

But this doesn't work in destiny as they aren't relative paths and the graph can't be built. I don't know if this issue becomes irrelevant when using destiny or not, but it does make it harder to start using it.

[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.