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). 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" 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?