Argument of type 'IconPack' is not assignable to parameter of type 'IconDefinitionOrPack' #125

ehujdur · 2019-02-05T12:05:13Z

Describe the problem

Trying to import fab icons to angular project, but cli says there's the following error:

error TS2345: Argument of type 'IconPack' is not assignable to parameter of type 'IconDefinitionOrPack'. Type 'IconPack' is missing the following properties from type 'IconDefinition': icon, prefix, iconName

The text was updated successfully, but these errors were encountered:

devoto13 · 2019-02-05T12:54:52Z

@ehujdur Can you also add your code, which leads to this error?

AvogadroSG1 · 2019-02-13T14:37:05Z

I have this issue loading Regular Icons.

import { NgModule } from '@angular/core';
import { CommonModule } from '@angular/common';
import { FontAwesomeModule } from '@fortawesome/angular-fontawesome';
import { NgbModule } from '@ng-bootstrap/ng-bootstrap';
import { FormsModule, ReactiveFormsModule } from '@angular/forms';
import { HttpClientModule } from '@angular/common/http';
import { library } from '@fortawesome/fontawesome-svg-core';
import { fas } from '@fortawesome/pro-solid-svg-icons';
import { far } from '@fortawesome/pro-regular-svg-icons';
import { CreateProjectComponent } from './create-project/create-project.component';
import { CreateProjectWebprojectComponent } from './create-project-webproject/create-project-webproject.component';
import { CreateProjectChangeworkorderComponent } from './create-project-changeworkorder/create-project-changeworkorder.component';
import { ProjectDashboardComponent } from './project-dashboard/project-dashboard.component';
import { ProjectsRoutingModule } from './projects-routing.module';
import { CreateProjectCreateTaskComponent } from './create-project-create-task/create-project-create-task.component';

library.add(fas);
library.add(far);

devoto13 · 2019-02-14T13:44:06Z

Can you mention versions of @fortawesome/fontawesome-svg-core and @fortawesome/pro-regular-svg-icons packages you use?

AvogadroSG1 · 2019-02-21T14:29:15Z

Hi! I'm very sorry for the delay.

devoto13 · 2019-02-21T14:43:57Z

Do you use both @fortawesome/fontawesome-pro and @fortawesome/angular-fontawesome in the same project? This may be the source of the issue. Try removing @fortawesome/fontawesome-pro if you don't use it.

AvogadroSG1 · 2019-02-21T14:47:39Z

Did try this with and without because I wasn't sure. I removed it, still have the problem. Here's my module's FA imports and statements.

I also tried adding them together:

devoto13 · 2019-02-21T14:57:06Z

Managed to reproduce it, investigating.

devoto13 · 2019-02-21T15:13:23Z

So the issue seems to be that you ended up having two instances of @fortawesome/fontawesome-common-types of different versions installed.

Can you first try to open your package-lock.json/yarn.lock and search for "@fortawesome/fontawesome-common-types": {? Does it find more than one result? If so try changing @fortawesome/fontawesome-svg-core to ^1.2.12 and running npm install to force it to update and de-duplicate?

AvogadroSG1 · 2019-02-21T16:34:35Z

I couldn't get it to force the install, so I removed it from packages.json and then readded it. Now all point to ^0.2.15. (While before one was pointing to 0.2.12)

So the better question, is this an NPM issue or a deployment problem from the package?

devoto13 · 2019-02-21T16:37:24Z

It's is a consequence of how FontAwesome packages are structured. Let's keep this issue open, I'lll think how we can prevent this from happening in the future.

AvogadroSG1 · 2019-02-21T16:38:14Z

Thanks for your help!

AndreKoepke · 2019-05-23T09:39:11Z

I had the problem too, the solution was to add a missing import-statement.

@import "~@fortawesome/fontawesome-free/css/regular.css";
@import "~@fortawesome/fontawesome-free/css/solid.css";
@import "~@fortawesome/fontawesome-free/css/fontawesome.css";
@import "~@fortawesome/fontawesome-free/css/brands.css"; // <- this one was missing

caleuanhopkins · 2019-06-28T12:08:26Z

Hey so running into this issue also. Been using Pro on an angular 7 project for months, no issues what so ever. Tried to load the faGoogle icon and get these errors:

package.json:

    "@fortawesome/angular-fontawesome": "^0.3.0",
    "@fortawesome/fontawesome-svg-core": "^1.2.12",
    "@fortawesome/free-brands-svg-icons": "^5.9.0",
    "@fortawesome/free-regular-svg-icons": "^5.9.0",
    "@fortawesome/pro-light-svg-icons": "^5.6.3",
    "@fortawesome/pro-regular-svg-icons": "^5.6.3",
    "@fortawesome/pro-solid-svg-icons": "^5.6.3",

devoto13 · 2019-06-28T12:10:40Z

@caleuanhopkins Can you try to perform steps described in #125 (comment) to see if you have two instances of the @fortawesome/fontawesome-common-types package?

caleuanhopkins · 2019-06-28T12:14:56Z

Can only find the 1 instance in the lock file and looks like all the libraries are loading the correct version in their dependency:

devoto13 · 2019-06-28T12:30:30Z

@caleuanhopkins Something looks odd, e.g.: @fortawesome/pro-light-svg-icons is of version ^5.6.3 in the package.json and 5.8.2 in your package-lock.json screenshot. Can you ensure that these are from the same project and same version of the project and you have run npm install?

caleuanhopkins · 2019-06-28T12:34:08Z

Ok apologies! 🤦‍♂

Using Yarn to install packages and noticed after I remove the package-lock.json that yarn has it's own lock.json file and yes I can see more than 1 @fortawesome/fontawesome-common-types package.

have removed the incorrect package now from the yarn.lock, reinstalled node_modules and is working now 👍

devoto13 · 2019-08-08T13:17:57Z

Please check #125 (comment) for instructions how to diagnose and workaround this issue.

epstarr · 2019-10-04T13:34:03Z

Running into the issue mentioned above, my package.json and package-lock.json look like this:

What I've done to get it to work is clear out lines 2549-2555 in my package-lock.json file, and change line 2548 to
"@fortawesome/fontawesome-common-types": "^0.2.22"
to match with the other packages.

However, I can't keep having to do this after each npm install, especially when builds are built and deployed through CI. Since all my packs are the same version, why does the brands one have this extra dependency and it requires a different version of the @fortawesome/fontawesome-common-types?

EDIT: Turns out I didn't have @fortawesome/fontawesome-common-types added to my package.json. Adding that has fixed the error permanently. I guess I was confused as the README doesn't say to install this as well?

devoto13 · 2019-10-04T19:01:19Z

@epstarr Explicitly specifying @fortawesome/fontawesome-common-types is one possible solution. But this is an internal dependency of other packages, so normally you should not need to specify it. This issue needs to be fixed for this to work correctly though.

Your approach didn't work, because @fortawesome/free-brands-svg-icons 5.11.1 does require @fortawesome/fontawesome-common-types 0.2.24 or newer (so 0.2.22 does not satisfy the requirement). That's why hoisting didn't happen. What you may do instead is to either remove all records related to @fortawesome/* packages from the package-lock.json and run npm install to get all the latest versions or alternatively remove all records for @fortawesome/fontawesome-common-types and it should probably hoist as well.

PatricNox · 2020-06-30T11:35:51Z

Removing the yarn.lock file and running install again solved it, thanks!
Maybe a package-lock.json & yarn.lock interference?

I of course don't use both, but I know that a new team mate may or may not have been fiddling around this.

arno-developer · 2020-07-06T18:47:28Z

I had the same issue, but the cause of my issue was that my @fortawesome/free-brands-svg-icons package was one (1) version newer than the rest of the fontawesome packages

tqmvt · 2022-02-23T13:03:07Z

Fixed issue by using IconDefinition

import { library, IconDefinition } from '@fortawesome/fontawesome-svg-core';
import {
  faTwitter,
  faGithub,
  faDiscord,
  faTelegram,
  faMedium
} from '@fortawesome/free-brands-svg-icons';
import { FontAwesomeIcon } from '@fortawesome/vue-fontawesome';

library.add(
  faTwitter as IconDefinition,
  faGithub as IconDefinition,
  faDiscord as IconDefinition,
  faTelegram as IconDefinition,
  faMedium as IconDefinition
);

mightykip · 2022-02-25T06:28:27Z

I've tried everything.

Here's what is in my package.json:

"@fortawesome/angular-fontawesome": "^0.8.2",
"@fortawesome/fontawesome-svg-core": "^1.3.0",
"@fortawesome/free-brands-svg-icons": "^5.15.4",
"@fortawesome/free-regular-svg-icons": "^5.15.4",
"@fortawesome/free-solid-svg-icons": "^5.15.4",

Every time I run an 'npm install' I get multiple versions of "@fortawesome/fontawesome-common-types" so I get the error:

Types of property 'iconName' are incompatible.

If I hand edit the package-lock.json file and remove the duplicates everything works... but every time I run 'npm install' I have duplicates again.

Can anyone please help?

Our build script automatically runs 'npm install' so the build always fails.

If it helps my node version is v16.14.0 and for npm I've tried versions 6, 7, and 8 with the same problem.

PatricNox · 2022-02-25T10:17:04Z

Can anyone please help?

if you remove the .lock file and run npm install, does it still cause duplicates?

mightykip · 2022-02-25T15:32:49Z

if you remove the .lock file and run npm install, does it still cause duplicates?

Yes, I still get duplicates if I delete the .lock file.

mightykip · 2022-02-25T23:03:42Z

faTwitter as IconDefinition

It's not ideal but this solution did work for now.

Thanks @launchdex !

devoto13 · 2022-02-27T14:58:56Z

Hey @mightykip, Sorry for the late response!

I've rasied this problem upstream in FortAwesome/Font-Awesome#16592 (comment). To resolve it on your side (for now), please change "@fortawesome/fontawesome-svg-core": "^1.3.0" to "@fortawesome/fontawesome-svg-core": "~1.2.36" and npm install.

I hope that my proposal will get accepted and we can finally resolve this type compatibility mess.

I've also created #346, which I'm going to look into once I have a response to my proposal.

robmadole · 2022-03-10T21:54:01Z

We are implementing @devoto13's proposal (it's a good one!) and it will be available in 6.1.0.

devoto13 · 2022-03-11T11:53:01Z

@robmadole Will this part of the proposal be implemented as well? It is crucial as otherwise, people will keep facing the same problem because ^1.2.x will automatically install 1.3.0 and cause the error. E.g. #350

I think we should publish @fortawesome/fontawesome-svg-core 6.0.0 and @fortawesome/fontawesome-common-types 6.0.0, then mark @fortawesome/fontawesome-svg-core 1.3.0 and @fortawesome/fontawesome-common-types 0.3.0 as deprecated, so that package managers will avoid these versions when resolving ^1.2.14 range, but will keep these version published to avoid breaking people who have already installed them.

robmadole · 2022-03-11T21:59:22Z

@devoto13 yes. I'll be deprecating those. I will also be pinning each of the icon packages (like @fortawesome/free-solid-svg-icons) to use @fortawesome/fontawesome-svg-core at 6.1.0 instead of ^6.1.0. It just doesn't make sense to let that dependency be out of sync with the exact version of the icon packages.

I think at one point we thought it might be useful to release these things with patch releases outside the normal Font Awesome release process. But that idea hasn't panned out (we've never done that to my knowledge.) So it makes sense to just keep all these version grouped together and all dependencies will match.

robmadole · 2022-03-16T15:43:21Z

Ok @devoto13 both of those packages are now deprecated. Hopefully that will clean up the mess! Thanks again for helping us with this one.

It also resolves FortAwesome#125 as there is now a clear rule for how to avoid type mess - make sure that versions of the Font Awesome packages are aligned. Now that Font Awesome 6 is stable, we make repository v6-first and only test v5 for compatibility. Fixes FortAwesome#351 Closes FortAwesome#125

It also resolves #125 as there is now a clear rule for how to avoid type mess - make sure that versions of the Font Awesome packages are aligned. Now that Font Awesome 6 is stable, we make repository v6-first and only test v5 for compatibility. Fixes #351 Closes #125

Husdady · 2022-08-05T19:13:01Z

Hi developer, I haver another other solution for this problem:

`
import { fas } from '@fortawesome/free-solid-svg-icons'
import { fab } from '@fortawesome/free-brands-svg-icons'
import { far } from '@fortawesome/free-regular-svg-icons'
import { library, IconPack } from '@fortawesome/fontawesome-svg-core'

library.add(
far as IconPack,
fas as IconPack,
fab as IconPack
)
`

rubenheymans · 2023-02-20T21:35:42Z

I had to set the versions fixed to make it work. deleted package-lock and ran npm i again

    "@fortawesome/angular-fontawesome": "0.11.1",
    "@fortawesome/fontawesome-svg-core": "6.2.1",
    "@fortawesome/free-brands-svg-icons": "6.2.1",
    "@fortawesome/free-solid-svg-icons": "6.2.1",

With this change `angular-fontawesome` exposes more permissive variants of some types (`IconPrefix`, `IconName`, `IconLookup`, `IconDefinition` and `IconPack`) from the `fontawesome-svg-core`. These new types allow arbitrary string values as icon name and icon prefix while maintaining auto-completion for the core Font Awesome icons. Firstly, this makes it possible to define and use custom icons without any casts, thus implementing part of the FortAwesome#172 and addressing part of the FortAwesome#423 (Kit packages with custom icons). The documentation for custom icons is coming later in a separate PR. Secondly, this makes `angular-fontawesome` resilient to multiple instance of `fontawesome-common-types` packages, thus helps with issues like FortAwesome#125. The drawback of this change is that if a user makes a typo in a core icon name or an icon prefix it will no longer produce a compile-time error, but will throw a runtime error instead. However, this trade-off seems to be overall the best option. Considerations: 1. To keep type safety while supporting custom icons, we'll need to somehow extend the mentioned icon types. It was investigated in the FortAwesome#172 (comment). The conclusion is that it requires very convoluted code to be added to the project and therefore is undesired. 2. For the explicit reference approach, the type safety/completion is not really needed as icon definitions are imported as runtime symbols and importing a symbol which does not exist will always result in complication error. 3. For the icon library approach, the type safety isn't perfect either. While it will catch cases where one specifies a completely incorrect icon name, it does not catch all problems. Icons are added to the library at runtime and if an icon name is correct, but the icon was not added to the library it will still result in a runtime error.

With this change `angular-fontawesome` exposes more permissive variants of some types (`IconPrefix`, `IconName`, `IconLookup`, `IconDefinition` and `IconPack`) from the `fontawesome-svg-core`. These new types allow arbitrary string values as icon name and icon prefix while maintaining auto-completion for the core Font Awesome icons. Firstly, this makes it possible to define and use custom icons without any casts, thus implementing part of the #172 and addressing part of the #423 (Kit packages with custom icons). The documentation for custom icons is coming later in a separate PR. Secondly, this makes `angular-fontawesome` resilient to multiple instance of `fontawesome-common-types` packages, thus helps with issues like #125. The drawback of this change is that if a user makes a typo in a core icon name or an icon prefix it will no longer produce a compile-time error, but will throw a runtime error instead. However, this trade-off seems to be overall the best option. Considerations: 1. To keep type safety while supporting custom icons, we'll need to somehow extend the mentioned icon types. It was investigated in the #172 (comment). The conclusion is that it requires very convoluted code to be added to the project and therefore is undesired. 2. For the explicit reference approach, the type safety/completion is not really needed as icon definitions are imported as runtime symbols and importing a symbol which does not exist will always result in complication error. 3. For the icon library approach, the type safety isn't perfect either. While it will catch cases where one specifies a completely incorrect icon name, it does not catch all problems. Icons are added to the library at runtime and if an icon name is correct, but the icon was not added to the library it will still result in a runtime error.

fontanon · 2024-08-14T07:40:36Z

Hey @mightykip, Sorry for the late response!

I've rasied this problem upstream in FortAwesome/Font-Awesome#16592 (comment). To resolve it on your side (for now), please change "@fortawesome/fontawesome-svg-core": "^1.3.0" to "@fortawesome/fontawesome-svg-core": "~1.2.36" and npm install.

I hope that my proposal will get accepted and we can finally resolve this type compatibility mess.

I've also created #346, which I'm going to look into once I have a response to my proposal.

Worked like a charm. Thanks.

AndreKoepke mentioned this issue May 23, 2019

telegram-plane does not work FortAwesome/Font-Awesome#13338

Closed

devoto13 changed the title ~~Importing font awesome brand icons doesn't work~~ Argument of type 'IconPack' is not assignable to parameter of type 'IconDefinitionOrPack' Aug 8, 2019

devoto13 pinned this issue Aug 8, 2019

devoto13 mentioned this issue Aug 8, 2019

Added component for working with Duotone icons #158

Merged

devoto13 added this to the 0.6.0 milestone Aug 9, 2019

devoto13 mentioned this issue Sep 24, 2019

Update file to reference library.add instead of library.addIcons #185

Closed

devoto13 mentioned this issue Jan 10, 2020

addIconPacks not work with fab #217

Closed

devoto13 removed this from the 0.6.0 milestone Feb 29, 2020

devoto13 mentioned this issue Mar 26, 2020

Type '"bacteria"' is not assignable to type 'IconName' #236

Closed

devoto13 mentioned this issue May 7, 2020

Feature request: Make SVG with JS packages resilient to multiple instances of fontawesome-common-types FortAwesome/Font-Awesome#16592

Closed

3 tasks

devoto13 mentioned this issue Jul 5, 2020

Unable to add the @fortawesome/free-brands-svg-icons to the FaIconLibrary #261

Closed

devoto13 mentioned this issue Feb 21, 2022

TS2322: Type 'IconDefinition' is not assignable to type 'IconProp' with FA 6 #345

Closed

devoto13 mentioned this issue Feb 27, 2022

Make it possible to select FontAwesome 5 vs FontAwesome 6 in ng add command #346

Closed

rrd108 mentioned this issue Mar 1, 2022

Argument of type 'IconPack' is not assignable to parameter of type 'IconDefinitionOrPack' FortAwesome/vue-fontawesome#353

Closed

devoto13 mentioned this issue Mar 18, 2022

Allow fontawesome-svg-core ^6.1.0 as a valid peer dependency #353

Merged

devoto13 unpinned this issue Mar 18, 2022

devoto13 closed this as completed in #353 Mar 18, 2022

yiyi1026 mentioned this issue Feb 9, 2023

Type 'IconDefinition' is not assignable to type 'IconProp' with Typescript FortAwesome/react-fontawesome#366

Closed

devoto13 mentioned this issue Apr 17, 2024

Introduce more permissive icon types #436

Merged

Argument of type 'IconPack' is not assignable to parameter of type 'IconDefinitionOrPack' #125

Argument of type 'IconPack' is not assignable to parameter of type 'IconDefinitionOrPack' #125

Comments

ehujdur commented Feb 5, 2019

Describe the problem

devoto13 commented Feb 5, 2019

AvogadroSG1 commented Feb 13, 2019 • edited Loading

devoto13 commented Feb 14, 2019

AvogadroSG1 commented Feb 21, 2019

devoto13 commented Feb 21, 2019

AvogadroSG1 commented Feb 21, 2019 • edited Loading

devoto13 commented Feb 21, 2019

devoto13 commented Feb 21, 2019 • edited Loading

AvogadroSG1 commented Feb 21, 2019

devoto13 commented Feb 21, 2019

AvogadroSG1 commented Feb 21, 2019

AndreKoepke commented May 23, 2019

caleuanhopkins commented Jun 28, 2019

devoto13 commented Jun 28, 2019

caleuanhopkins commented Jun 28, 2019

devoto13 commented Jun 28, 2019

caleuanhopkins commented Jun 28, 2019

devoto13 commented Aug 8, 2019

epstarr commented Oct 4, 2019 • edited Loading

devoto13 commented Oct 4, 2019 • edited Loading

PatricNox commented Jun 30, 2020

arno-developer commented Jul 6, 2020

tqmvt commented Feb 23, 2022 • edited Loading

mightykip commented Feb 25, 2022 • edited Loading

PatricNox commented Feb 25, 2022

mightykip commented Feb 25, 2022 • edited Loading

mightykip commented Feb 25, 2022

devoto13 commented Feb 27, 2022 • edited Loading

robmadole commented Mar 10, 2022

devoto13 commented Mar 11, 2022

robmadole commented Mar 11, 2022

robmadole commented Mar 16, 2022

Husdady commented Aug 5, 2022

rubenheymans commented Feb 20, 2023

fontanon commented Aug 14, 2024

AvogadroSG1 commented Feb 13, 2019 •

edited

Loading

AvogadroSG1 commented Feb 21, 2019 •

edited

Loading

devoto13 commented Feb 21, 2019 •

edited

Loading

epstarr commented Oct 4, 2019 •

edited

Loading

devoto13 commented Oct 4, 2019 •

edited

Loading

tqmvt commented Feb 23, 2022 •

edited

Loading

mightykip commented Feb 25, 2022 •

edited

Loading

mightykip commented Feb 25, 2022 •

edited

Loading

devoto13 commented Feb 27, 2022 •

edited

Loading