RFC: Improving support for auto-imports in an Analog SFC

[brandonroberts]

For an Analog SFC, we support auto-adding of .analog files to the imports array of the underlying component.

<script lang="ts">
import MyComponent from './my-component.analog';
</script>

<template>
  <MyComponent />
</template>

We do this by identifying the filename of the originating analog file. This works well for importing single files. It does not work for analog files imported from libraries or barrel files

<script lang="ts">
import { MyComponent } from '@my-lib/components';
</script>

<template>
  <MyComponent />
</template>

To resolve this issue we are looking at using import attributes:

Import Attributes (Stage 3 proposal, available in TypeScript 5.3)

Import attributes are supported in TypeScript 5.3+ and allow us to use an existing standard for imports that declares them available for the template

<script lang="ts">
import SimpleAnalog from './simple.analog' with { type: 'template' };

import DefaultFromLib from '@external/lib' with { type: 'template' };
import { NamedFromLib } from '@external/lib-two' with { type: 'template' };

import { RouterOutlet } from '@angular/router' with { type: 'template' }; // works too!
import { Router } from '@angular/router';
</script>

• This would require a minimum of Angular v17.1+
• The import block can be more noisy, but also hidden away within IDEs
• IDE Support for auto-importing may need some enhancements

One caveat is that non-template imports could not be included in the same import block

<script>
  import { Router, RouterOutlet } from '@angular/router' with { type: 'template' };
</script>

<template>
  <router-outlet></router-outlet>
</template>

Alternatives

Import analysis with ts-morph

Currently, we are loading analog SFCs in ts-morph to compile them into TypeScript source. We could use some analysis based on Import Declarations but this approach is prone to errors and performance implications.

Template Imports

Another alternative would be to declare the imports inside the template block that are made available to the template

<template>
  import { MyComponent } from '@my-lib/components';
  <MyComponent />
</template>

or

<template>
  <imports>  
    import { MyComponent } from '@my-lib/components';
  </imports>

  <MyComponent />
</template>

This has a pitfall of making it hard to parse with IDEs already supporting Angular and Analog component authoring and syntax highlighting, including an upcoming release of WebStorm.

[joshuamorony]

It looks like we can use any key in the with object:

interface ImportAttributes {
    [key: string]: string;
}

If we go with import attributes I propose using it more broadly to replace some aspects of defineMetadata with a meta or metadata key (it would still be required in cases, but would eliminate the need for a lot of cases)

The meta key used would just reflect where the import would typically be placed in defineMetadata

Example:

<script lang="ts">
import DefaultFromLib from '@external/lib' with { meta: 'imports' }; 
import { FormsModule } from '@angular/forms' with { meta: 'imports' };

import { StateService } from './data-access/state.service' with { meta: 'providers' }

import { myFunc } from './somewhere' with { meta: 'exposes' }
</script>

[AdditionAddict]

happy with import attributes

[luishcastroc]

Import attributes for the win

[ilirbeqirii]

Sorry for asking, maybe a noob question but just wanted to ask, how would import attributes solve this problem?

[brandonroberts]

If we identify an import using with { type: 'template' }, then we will know to add it to the imports of the class component we generate underneath.

<script lang="ts">
import { MyComponent } from '@my-lib/components' with { type: 'template' };
import { RouterOutlet } from '@angular/router' with { type: 'template' };
</script>

<template>
  <MyComponent />
  <router-outlet />
</template>

Turns into

import { MyComponent } from '@my-lib/components';
import { RouterOutlet } from '@angular/router';

@Component({
  imports: [MyComponent, RouterOutlet],
  template: `
      <MyComponent />
      <router-outlet />
  `
})
export class AnotherComponent {}

The Angular team is looking at something also with just standalone components

import { MyComponent } from '@my-lib/components'; // inferred using the compiler
import { RouterOutlet } from '@angular/router';

@Component({
  imports: [RouterOutlet], // May still be recommended practice
  template: `
      <MyComponent />
      <router-outlet />
  `
})
export class AnotherComponent {}

As Josh mentioned, we could use it for other imports that can translate into component metadata