I2I/Discussion: Absolute or aliased imports in AMP code

# Absolute import paths in AMP

## Overview

AMP code has a wide range of dependencies, some of which can be unclear. These imports are referenced using relative paths like `../../../src/utils/math`. This can be annoying to read and type, and can obscure some of the relationships between a source file and its dependencies (related: [#32693](https://github.com/ampproject/amphtml/issues/32693)). This becomes especially relevant as we create a Bento codebase that needs to be independent of AMP services.

## Early-stage Idea

We're exploring the idea of supporting some form of absolute or aliased import paths. **The objective is to identify if this idea is worth pursuing further, not necessarily to arrive at a final design.** All proposals below have been confirmed to be workable in our build systems and VSCode integrations.

## Some possibilities

First, a comparison from the developer experience view before discussing the tradeoffs of each. Taken from `'extensions/amp-base-carousel/1.0/base-carousel.js'`.

### Current


### Absolute paths


### Aliased paths


### Package-like paths


## Pros & Cons

### All variants (except Current) listed above/below

* **Example:** `'../../../src/core/types`, `'../../../src/preact/context'`, `'../../amp-lightbox-gallery/1.0/component'`
* **Pros:** easily supported by build systems, native support in VSCode integration, import stability when moving files, shorter imports/no `../../../..` soup, visual clarity in dependencies
* **Cons:** a new layer of indirection/complexity, a new convention for AMP devs to learn, time spent on something many devs don't think about/rely on IDE for

### Absolute paths

* **Examples:** `'src/core/types'`, `'src/preact/context'`, `'extensions/amp-lightbox-gallery/1.0/component'`
* **Pros:** fairly common in JS projects, trivial to understand, better read/write-ability
* **Cons:** slight risk of namespace collision with `node_modules`

### Aliased paths

* **Examples:** `'#core/types'`, `'#preact/context'`, `'#extensions/amp-lightbox-gallery/1.0/component'`
* **Pros:** clear "entry-points" (core, preact, services, extensions, etc), easy to read/group imports, clear dependencies across top-level directories, follows built-in subpath imports supported by package.json, [possible to swap "target"](https://nodejs.org/api/packages.html#packages_subpath_imports) from local source to npm package (ie. Bento core package)
* **Cons:** more indirection, less commonly seen in other projects

### Package-like paths

* **Examples:** `'@ampproject/core/types'`, `'@ampproject/preact/context'`, `'@ampproject/extensions/amp-lightbox-gallery/1.0/component'`
* **Pros:** all benefits of aliased paths, more familiar to devs, mirrors how external projects might import from npm packages
* **Cons:** misleading (not actually importing from npm packages), more verbose

## Key Questions

* Is this worth exploring more deeply?
* Do you think this would have any impact (positive or negative) on your developer experience?
* If so, which of the options above seem most appealing to you?

Start with the import examples in extensions/amp-base-carousel/1.0/base-carousel.js and compare the current, absolute, aliased, and package-like options described in the issue. Review the listed pros, cons, and Node.js package subpath reference, then document whether further exploration is warranted and which option best addresses AMP and Bento development needs.

Written by the indexing model from the issue text.