[discuss] Use mapping aliases instead of relative imports between plugins

[tylersmalley]

In Bazel, relative imports will no longer work across plugin or package boundaries. One of the solutions we investigated in #91056 was using aliases. We would like to raise this as a solution and see if there are any objections to the proposed change.

For example, an existing import within data plugin importing from another plugin:

import { SavedObjectNotFound } from '../../../../../../plugins/kibana_utils/common';

would become:

import { SavedObjectNotFound } from 'src/plugins/kibana_utils/common';

Prefixing this location with something like @kbn is also an option, however, I fear that would cause more confusion than just using an absolute path from the root of the repository. Some other naming options could be @kbn-ref, @kbn-int, etc.

To accomplish this for Typescript, we would define the paths in tsconfig.base.json

{
  "compilerOptions": {
    "paths": {
      "src/plugins/*": [
        "src/plugins/*"
      ],
      "x-pack/plugins/*": [
        "x-pack/plugins/*"
      ],
      "src/core/*": [
        "src/core/*"
      ],
    },
    ...
  }
  ...
}

Relative imports which are used within its own plugin would not change. This is only when a plugin is importing from another plugin.

In order to enforce this, we would create an auto-fixable ESLint rule. This way if anyone does use a relative import, it will be easy to resolve.

In the future, we would example on these paths to include all of the platform-specific Bazel outputs (bazel-out/darwin-fastbuild/bin/src/plugins, bazel-out/k8-fastbuild/bin/src/plugins, etc).

Bazel RFC: #92758
Related: #91056

[stacey-gammon]

I like the idea of using something like @kbn-ref over absolute file paths because it will let us rearrange our folder hierarchy without needing to refactor all the import paths.

[tylersmalley]

An update to this issue - we have recently begun discussing using npm imports for plugins, similar to packages.