Argument of type 'SPHttpClientConfiguration' is not assignable to parameter of type 'SPHttpClientConfiguration'

[BigEaseGueldi]

After upgrading to new SPFx versions, the error above appears for SPFx solutions with calls via the SPHttpClient.

Current framework version: 1.3.4

Category

• Question
• Typo
• Bug
• Additional article idea

Expected or Desired Behavior

If you update the SPFx parts of your package.json and run an npm install, this error should not appear.

Observed Behavior

Each time I update the SPFx parts of package.json ...

• ... I need to delete the contents of my node-modules folder OR
• ... I need to delete only the node_modules subfolder of @microsoft/sp-webpart-base and this is the place where the other SPHttpClientConfiguration is (my current best approach).

Steps to Reproduce

See above.

Thanks for your help!
Dirk

[BigEaseGueldi]

Adding related issues:
#365
#911

[waldekmastykarz]

I'd say the need to refresh all dependencies in the node_modules folder (meaning, deleting the whole folder and running npm install) is by design: after all you can't quite tell which dependencies have changed and you need to refresh all of them to ensure that they are in sync.

[BigEaseGueldi]

Thanks @waldekmastykarz for your input! Though it somehow doesn't feel like the most sophisticated approach, I also found the instruction to delete the node_modules folder content here:

https://docs.microsoft.com/en-us/sharepoint/dev/spfx/toolchain/update-latest-packages

So I'll just stick with the plan for now. -> Closed

@VesaJuvonen : Any chance for future improvement here? Think of guys with 15 SPFx solutions on their local machine (i.e. 15 x ~30.000 files). Especially with the future possibility to roll out SPFx things via the Site Collection App Catalog, I expect to see even more solutions with less Web Parts and/ or Extensions (i.e. only 1 per solution) and thus more efforts for keeping them up to date.

[waldekmastykarz]

It's a trade off: having more smaller solutions gives you more deployment flexibility but requires more maintenance, not only for developers but also for administrators - just like you mentioned. Combining multiple components into a single solution simplifies the management but offers less flexibility with regards to which components should be deployed where. I don't think there is one approach that's the best and you will have to choose what makes sense for each scenario.

[andrewconnell]

IMHO, no need to change that process... it's not uncommon with other projects that rely on package managers (Node.js & NPM or .NET & NuGet). From my POV, don't have a "special SharePoint case"...

[msft-github-bot]

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues