Mark Angular component as "standalone: false"

[Martinspire]

Package

• lucide
• lucide-angular
• lucide-flutter
• lucide-preact
• lucide-react
• lucide-react-native
• lucide-solid
• lucide-svelte
• lucide-vue
• lucide-vue-next
• Figma plugin
• source/main
• other/not relevant

Version

0.473.0

Can you reproduce this in the latest version?

• Yes
• No

Browser

• Chrome/Chromium
• Firefox
• Safari
• Edge
• iOS Safari
• Opera
• Other/not relevant

Operating system

• Windows
• Linux
• macOS
• ChromeOS
• iOS
• Android
• Other/not relevant

Description

With Angular 19, all components are assumed to be Standalone. But while the version is supported as a dependency, the component is still breaking support by not explicitly setting standalone.

Since the issue about making the library standalone isn't going anywhere and lots of stuff is planned but not yet executed, there's issues with the current approach for when you want to write tests.

In Angular its common to use NG-Mocks for testing, but that currently doesn't know that the component is standalone. It gives a similar error as this: help-me-mom/ng-mocks#10762 for Lucide

There's a discussion happening with ng-mocks but no real solution is out yet, but this project should still set the value to make sure people also know it isn't a standalone dependency yet.

Steps to reproduce

1. Import module in your project
2. Use icon somewhere
3. Write test and either include or mock the library (it doesn't seem to matter as far as I know)
4. Unit tests break because component is assumed to be standalone but still imported in an ngmodule.

Checklist

• I have searched if someone has submitted a similar issue before and there weren't any. (Please make sure to also search closed issues, as this issue might already have been resolved.)

[karsa-mistmere]

@Martinspire: that's gonna be a tough nut to crack, since Angular 19 is still only being used by a very small number of projects compared to earlier versions that have no standalone support: https://www.npmjs.com/package/@angular/core?activeTab=versions

As such, I'd rather leave lucide-angular backwards compatible and instead focus on shipping our @lucide/angular package with standalone support.

[Martinspire]

@karsa-mistmere I think we're not on the same page here. Let me elaborate. My point is not to make the project standalone. My point is to make sure its not. By using standalone: false you are actually keeping it backwards compatible. Right now it stops working when you use stuff like ng-mocks (or other mocking solutions) because Angular assumes that lucide is standalone, when it is actually part of an NgModule.

With Angular v19, they moved from assuming components are not standalone, to assuming they are. Thus everybody that used standalone could remove the standalone: true flag, where people that weren't using standalone, needed to add standalone: false. Its the same thing but different default values. The migration script hasn't been run with the Angular 19 update on this project, so the standalone flag is missing to keep it backwards compatible.

It should be a small fix that has no effect for people that are not standalone. The standalone migration for this project itself, is something that I would love to see, but I understand why it hasn't happened yet.

[karsa-mistmere]

I understood what you meant, it's just that we cannot add standalone: false to the component without breaking support for earlier versions of Angular where the standalone prop doesn't even exist.

[Martinspire]

But if it doesn't exist, they won't be updating either, since other dependencies would also break?

And if you do not make the change, the result is that the current project then doesn't support Angular 19.

Part of migrating to the new Angular version is the standalone flag, so any project moving to that, will want it reflected.

Standalone flag was introduced in Angular 14 in 2022. Its not that new for projects to start using it, even if they don't want to migrate to 19 yet. And if this change isn't made, the only option for me is to either fork it or to use the static library instead. Because this project then has no future for me if standalone isn't properly supported. Requiring Angular 14 isn't too much of a breaking change I'd say.

But I can also live with a separate component that works with standalone. I don't need it to be the exact same name anyway. If the component is now called LucideAngular19Component or the module LucideAngular19Module I could still live with the changes. Heck, a LucideComponent would already be simpler too and you could start building Standalone from there. No need to completely overhaul the project.

[karsa-mistmere]

Since our Angular package doesn't rely on exporting separate icon components per icon, we intend to decouple the business logic from the icons themselves, providing a standalone icon component and related injection tokens and services as part of a new @lucide/angular package and the icon data as part of a separate dependency (something like @lucide/icons), this way we could keep users updated with new icons without having to worry about package compatibility issues – people could keep their @lucide/angular package version fixed and just keep @lucide/icons up to date (or possibly even use lucide-angular as their core package, but import icons from @lucide/icons).

In the future people could use @lucide/angular as such:

import { XIcon } from '@lucide/icons';
import { LucideIconComponent } from '@lucide/angular';

@Component({
  selector: 'app-foobar',
  standalone: true, // omitted in Angular v19
  imports: [LucideIconComponent],
  template: `<lucide-icon [img]="XIcon"/>`,
})
export class FoobarComponent {
  protected readonly XIcon = XIcon;
}

or when using icon providers as some currently do:

import { X } from '@lucide/icons';
import { LucideIconComponent, provideLucideIcons } from '@lucide/angular';

@Component({
  selector: 'app-foobar',
  standalone: true, // omitted in Angular v19
  imports: [LucideIconComponent],
  template: `<lucide-icon name="x"/>`,
  providers: [provideLucideIcons({X})],
})
export class FoobarComponent {
}

[Martinspire]

@karsa-mistmere ok sure, but that isn't available yet, right? Not even a beta? Or a fork for v19?