SPFx 1.19.0 - Error during build with [object Object] errors that didn't happen in previous versions

[tandrasi]

Target SharePoint environment

SharePoint Online

What SharePoint development model, framework, SDK or API is this about?

💥 SharePoint Framework

Developer environment

Windows

What browser(s) / client(s) have you tested

• 💥 Internet Explorer
• 💥 Microsoft Edge
• 💥 Google Chrome
• 💥 FireFox
• 💥 Safari
• mobile (iOS/iPadOS)
• mobile (Android)
• not applicable
• other (enter in the "Additional environment details" area below)

Additional environment details

• browser version latest
• SPFx version 1.19.0
• Node.js version 18.20.2

Describe the bug / error

Everything else being equal, upgrading our current React projects from 1.18.2 to 1.19.0 causes us to get errors during webpack's build process. The issue is that it doesn't say what the errors are, just "[object Object]". Multiple error lines exist depending on the files included in the build. It is impossible to isolate what is exactly causing the issues, but I have a .ts file I know is causing at least one of the build failures (just reach out if you would like to see it).

Please note:

1. Using the Yeoman generator for 1.19.0 and provisioning a React webpart, it builds fine. Adding more and more of our code eventually will cause the error as per above.
2. We have upgraded correctly, ensuring to clear node_modules and even rebuilt the package.json file.
3. Some projects have been alive since 1.16.0 and upgraded correctly with each release without issue.

Steps to reproduce

1. Upgrade existing SPFx project to 1.19.0 or start from scratch;
2. Something will eventually trigger this error and I'm not sure what because it doesn't say!
3. Sadness

Expected behavior

I expect no errors in the build, just like there were no errors in previous SPFx versions.

[bornhamilton]

The same issue

[xavisegura]

Same issue, compared with ootb 1.19 generated webpart, same npm versions, webpack throws a bunch of [object Object] errors without further details.

[gabmor38]

Same issue

[jensotto]

I had the same exact issue.
For me it boiled down to some CSS references that where not done according to
documentation, and top level imports of Fluent UI components that for some reason used an unsupported reference path (deeper than for example @fluentui/react/lib/Pickers.

All of this worked fine in 1.18.2 but failed after upgrading to 1.19.0. After fixing the issues mentioned above all of those [object Object] errors disappeared in my project and all worked as before.

[tandrasi]

I had the same exact issue. For me it boiled down to some CSS references that where not done according to documentation, and top level imports of Fluent UI components that for some reason used an unsupported reference path (deeper than for example @fluentui/react/lib/Pickers.

All of this worked fine in 1.18.2 but failed after upgrading to 1.19.0. After fixing the issues mentioned above all of those [object Object] errors disappeared in my project and all worked as before.

OK, say that this is the case with import reference paths being longer, how would I fix the following imports? This snippet I'm showing from my ThemeProvider.ts file is definitely the culprit for 2 out of my 8 [object Object] errors because once I remove some of the property pane references from pnp/spfx-property-controls, it works:

import {
    ThemeProvider as msThemeProvider
} from '@microsoft/sp-component-base';
import ThemeGenerator from '../generators/ThemeGenerator';
import ColorHelper from '../helpers/ColorHelper';
import tinycolor from 'tinycolor2';
import IBaseThemingProps from '../typings/interfaces/base-webpart-props/IBaseThemingProps';
import { PropertyFieldColorPicker, PropertyFieldColorPickerStyle } from '@pnp/spfx-property-controls/lib/PropertyFieldColorPicker';
import { PropertyFieldSwatchColorPicker, PropertyFieldSwatchColorPickerStyle, IPropertyFieldSwatchColorOption } from '@pnp/spfx-property-controls/lib/PropertyFieldSwatchColorPicker';
import { IPropertyPaneDropdownOption, IPropertyPaneField, PropertyPaneToggle, PropertyPaneDropdown, PropertyPaneDropdownOptionType, PropertyPaneSlider } from '@microsoft/sp-property-pane';
import { update } from '@microsoft/sp-lodash-subset';
import BaseThemingPropsEnum from '../enums/BaseThemingPropsEnum';
import { createTheme, mergeStyles } from '@fluentui/react';
import WebFont from 'webfontloader';
import GoogleFontFamilies from '../data/GoogleFontFamilies';
import React from 'react';
import { PropertyPaneSeparator } from '../property-pane/PropertyPaneSeparator';
import { PropertyPaneSpacer } from '../property-pane/PropertyPaneSpacer';
import SPHelper from '../helpers/SPHelper';
import ThemeHelper from '../helpers/ThemeHelper';

[User5679]

Hello,
Similar issue here. The solution provided by @jensotto with reference paths worked for 3 over my 4 warnings.
However for the last one, it was coming from :
import { Placeholder } from "@pnp/spfx-controls-react/lib/Placeholder";

I tried several reference paths but none is working, apparently same as what @tandrasi has with pnp/spfx-property-controls.
So it appears to impact all kind of react component libraries.
Didn't find a workaround yet for this one (except embedding the component which is not the point obviously).

[eljacko1]

I was also having this issue recently. After trying a whole bunch of different things I eventually ran 'gulp serve --verbose' and noticed the error happened after loading the localisation files for the @pnp/spfx-property-controls. On a whim I deleted the contents of this folder node_modules/@pnp/spfx-property-controls/lib/loc in the project and suddenly it started working again.

I've no idea why, but I hope perhaps this information can help somehow.

I should also note, that the files I removed came back but the error has not returned

[tandrasi]

I was also having this issue recently. After trying a whole bunch of different things I eventually ran 'gulp serve --verbose' and noticed the error happened after loading the localisation files for the @pnp/spfx-property-controls. On a whim I deleted the contents of this folder node_modules/@pnp/spfx-property-controls/lib/loc in the project and suddenly it started working again.

I've no idea why, but I hope perhaps this information can help somehow.

I should also note, that the files I removed came back but the error has not returned

I tried this but it didn't work for me. I saw the files being found during "gulp serve --verbose" and deleted them as per recommendation. I still get the same amount of [object Object] errors (6 in my case - it used to be 8 but upgrading the property controls must've done something). I have even tried upgrading to the latest @pnp/spfx-property-controls version (3.17.0)

"@pnp/spfx-property-controls": "^3.17.0"

While this suggestion is great as a workaround and hope it helps others, this just wouldn't suffice, especially when we use Azure DevOps Pipelines for our builds.

This is a systemic issue that I hope someone from the dev team can at least acknowledge.

Thanks

[bornhamilton]

I’ve removed "@pnp/spfx-property-controls": "^3.17.0" from project and still see errors.

[ZabbyCapurin]

I'm currently seeing the errors for my pre-existing SPFx solution web part. For me, if the web part is using @pnp/spfx-property-controls, it gives the errors and doesn't build/publish.
Removing the web part from the build and deployment doesn't show the errors (using --verbose didn't do much for me) and builds my package file just fine

[tandrasi]

I'm currently seeing the errors for my pre-existing SPFx solution web part. For me, if the web part is using @pnp/spfx-property-controls, it gives the errors and doesn't build/publish. Removing the web part from the build and deployment doesn't show the errors (using --verbose didn't do much for me) and builds my package file just fine

Same, I use it extensively in our shared library and all our web parts. I have to stick to 1.18.2 until this is addressed.

[vystartasv]

Same here. Tried many things (upgrade/downgrade libraries/node/refactor code) with this error, but only solution for now - downgraded everything back to 1.18.2 :((

[mbice]

We are also blocked from upgrading many of our modules to 1.19 because of this issue.

[stevebeauge]

Both @pnp/spfx-controls-react and @pnp/spfx-property-controls are tighly coupled to the version of SPFx (see here for example.

You have to wait a SPFX 1.19 compatible release of the components in order to use them with latest spfx version.

That said, the SPFX teams burried the actual webpack configuration is a deep stack of build tools, which "simplifies" the use of the framework, until something breaks. In this case, it's pratically impossible to debug the faulting component.

I wish this part of the SPFX framework to get better documented and opened to customization.

[RedGlow]

Extremely hack-y way to debug this problem: go to node_modules/@microsoft/gulp-core-build-webpack/lib/WebpackTask.js, around line 84, and replace:

this.logError(`'${outputDir}':` + os_1.EOL + statsResult.errors.join(os_1.EOL) + os_1.EOL);

with:

this.logError(`'${outputDir}':` + os_1.EOL + statsResult.errors.map(x => JSON.stringify(x, null, 2)).join(os_1.EOL) + os_1.EOL);

In the printed objects you should find message, moduleName and loc to identify what the problem is. Probably will be in the compiled JS code instead of the TS, but still better than nothing.

[StfBauer]

This issue come from missing npm packages that web part uses. To get this solved you need to deploy the webpart as a dev build. While it will fail to load on the page it will tell you exactly what packages you need to install.

In my case webpack was missing core-js. Once I installed core-js package es6-map was missing in addition to that.

So I installed:

npm install -D core-js  es6-map

Once those missing npm packages where installed webpack started to work without any problem. it is a bit of a strange problem but with this I was able to get things running again.

It might could be that there are some other npm packages missing.

ping - @AJIXuMuK

[stevebeauge]

you need to deploy the webpart as a dev build

How can you do that if the webpart does not compile?

[StfBauer]

@stevebeauge for a dev build:

gulp bundle

followed by

gulp package-solution

Creates the sppkg file but does not include any sources inside the bundle. It gives you the ability to add the web part to the page and serve the files from localhost. Therfor it do not matter if the build works or not.

Once you serve it from localhost via:

gulp serve

You start to see the issue in the browser, why the webpack refused to load. Like I showed before the missing "modules" aka node_modules. Of course in order to add the web part you have to pass in on any page the common query parameter like this

?debug=true&noredir=true&debugManifestsFile=https://localhost:4321/temp/manifests.js

[MortenPedersenDK]

I get similar [object Object] errors. I used @RedGlow webpack logging hack above to get more information, and running

gulp build or gulp bundle

gives me this error and a lot of similar kind:

ModuleNotFoundError: Module not found: Error: Package path ./lib/components/Dropdown is not exported from package D://source//myproject//node_modules//@pnp//spfx-property-controls//node_modules//@fluentui//react (see exports field in D://source//myproject//node_modules//@pnp//spfx-property-controls//node_modules//@fluentui//react//package.json)
 at D://source//myproject//node_modules//webpack//lib//Compilation.js:2022:28
 at D://source//myproject//node_modules//webpack//lib//NormalModuleFactory.js:817:13
 at eval (eval at create (D://source//myproject//node_modules//tapable//lib//HookCodeFactory.js:33:10), <anonymous>:10:1)
 at D://source//myproject//node_modules//webpack//lib//NormalModuleFactory.js:275:22
 at eval (eval at create (D://source//myproject//node_modules//tapable//lib//HookCodeFactory.js:33:10), <anonymous>:9:1)
 at D://source//myproject//node_modules//webpack//lib//NormalModuleFactory.js:448:22
 at D://source//myproject//node_modules//webpack//lib//NormalModuleFactory.js:118:11
 at D://source//myproject//node_modules//webpack//lib//NormalModuleFactory.js:689:25
 at D://source//myproject//node_modules//webpack//lib//NormalModuleFactory.js:893:8
 at D://source//myproject//node_modules//webpack//lib//NormalModuleFactory.js:1013:5

When I look at the exports section of D://source//myproject//node_modules//@pnp//spfx-property-controls//node_modules//@fluentui//react//package.json, there is no ./lib/components/Dropdown, but a ./lib/Dropdown:

    "./lib/Dropdown": {
      "types": "./lib/Dropdown.d.ts",
      "import": "./lib/Dropdown.js",
      "require": "./lib-commonjs/Dropdown.js"
    },
    "./lib/components/Dropdown/Dropdown.styles": {
      "types": "./lib/components/Dropdown/Dropdown.styles.d.ts",
      "import": "./lib/components/Dropdown/Dropdown.styles.js",
      "require": "./lib-commonjs/components/Dropdown/Dropdown.styles.js"
    },

I tried installing @fluentui/react as per @StfBauer recommendation

npm install -D @fluentui/react

But it did not resolve the error. Could it be something like @fluentui/react has changed how the component is exported(to /lib/ instead of /lib/components)?

Update: I changed the imports to 'tree-shaking' approach as mentioned in @jensotto provided link. However, this did not change anything.

[tandrasi]

I've tried the two things @MortenPedersenDK mentioned above from @StfBauer and @jensotto , but no luck here either.

[MortenPedersenDK]

I think I have found out what the issue is:

In for example PropertyFieldDropdownWithCalloutHost in sp-dev-fx-property-controls there is the following import from @fluentui/react:

import { Dropdown, IDropdownProps, IDropdownOption } from '@fluentui/react/lib/components/Dropdown';

According to this blog post from March 2022 components in @fluentui/react has been relocated, and if you look at package.json of fluentui project you see the exported type is not in /lib/components but in /lib:

"./lib/Dropdown": {
      "types": "./lib/Dropdown.d.ts",
      "import": "./lib/Dropdown.js",
      "require": "./lib-commonjs/Dropdown.js"
    },

And according to fluentui wiki imports should be:

import { Dropdown } from '@fluentui/react';

Question is then how to deal with this besides downgrading to earlier version or changing all imports in @pnp projects and hope to get a pull request through fairly quickly?

[FredrikEkstroem]

@MortenPedersenDK Looks like my issue is the same as yours with the @pnp/spfx-property-controls. The reason seams to be that webpack 5 honors the exports section in package.json where webpack 4 ignored it. I'll try to add a PR over there and we'll see if it gets approved.

From copilot:
Starting from Node.js version 12, package authors can define an "exports" field in their package.json file to explicitly state which files can be imported from a package. This is intended to provide encapsulation, allowing package authors to change the internal structure of their package without affecting its public API.

Webpack 5 follows this Node.js specification, and therefore respects the "exports" field in package.json files. This means that you can only import files that are explicitly listed in the "exports" field.

Webpack 4, on the other hand, does not respect the "exports" field, and allows importing any file from a package.

So, if you're using Webpack 5 and trying to import a file that is not listed in the "exports" field of the @fluentui/react package, you will get an error. You will need to either import a file that is listed in the "exports" field, or ask the package authors to add the file you're trying to import to the "exports" field.

[JelleCeulemans]

I'm using SPFx version 1.19.0 from release date and the easiest way to get your project working is with this setup:

I also recommend to use the change of @RedGlow.

[b-ale94]

@JelleCeulemans 's fix worked just fine.
I had the [object object] error while importing this specific component PropertyFieldCollectionData.
Thank you very much, you saved me

[ssgalo]

Can anyone help me? I'm encountering the same error and this is what I'm seeing:

I'm trying to reference an image, but I'm not sure how to do it. The path is correct. Here is the code:

[tandrasi]

Can anyone help me? I'm encountering the same error and this is what I'm seeing:

I'm trying to reference an image, but I'm not sure how to do it. The path is correct. Here is the code:

This is a completely separate problem than the one outlined here, but it's a simple fix for you. You're just referencing the wrong relative folder - you need to jump up one folder higher (two dots below).

Do this:
const logo: any = require('../assets/vela.png' ) ;

Instead of your original:
const logo: any = require('./assets/vela.png' ) ;

[ZzyzxIsAlreadyTaken]

Im having the same problem. I believe it comes from something within radix-ui which I am importing via ShadCNui components.

[FredrikEkstroem]

At least some of these problems are because webpack 5 only allows imports that are specified in the exports part in package.json in the imported package. You can revert to the Webpack 4 way by adding below code to gulpfile.js.

build.configureWebpack.mergeConfig({
  additionalConfiguration: (generatedConfiguration) => {
    generatedConfiguration.resolve = generatedConfiguration.resolve || {};
    generatedConfiguration.resolve.exportsFields = [];
    return generatedConfiguration;
  },
});

[ZzyzxIsAlreadyTaken]

DId not change anything for me unfortunately. When I try to use a component that imports radix-ui I get the [object Object] error.

[vishalshitole]

I am also getting the same issue when I use latest stable version (3.x) of @pnp/spfx-controls-react and/or @pnp/spfx-property-controls.

I was able to resolve it using the beta versions as below.

However, I don't want to use the beta version of these packages in my enterprise solutions.

@VesaJuvonen @AJIXuMuK When should we expect the solution for this issue?

Environment details:

• Node version: 18.20.3
• SPFx version: 1.19.0

[JRRSG]

I am also getting the same issue when I use latest stable version (3.x) of @pnp/spfx-controls-react and/or @pnp/spfx-property-controls.

I was able to resolve it using the beta versions as below.

However, I don't want to use the beta version of these packages in my enterprise solutions.

@VesaJuvonen @AJIXuMuK When should we expect the solution for this issue?

Environment details:

• Node version: 18.20.3
• SPFx version: 1.19.0

Thank you, this was my exact issue

[AJIXuMuK]

Thank you for reporting and actively discussing the issue.
Migration from Webpack 4 to Webpack 5 is a huge change and could lead to errors in builds for custom solutions.
The release notes for SPFx 1.19 clearly mentioned that you may need to perform migration due to Webpack update.

Regarding PnP SPFx controls

• React controls don't have any issues unless for some reason you deleted ControlStrings property from the config.json (it is added automatically when the library is installed).
• Property controls issues were fixed in the latest version this weekend. Please, update to 3.17.1.

I'm going to close this issue as there is no error in the SPFx itself.

[Ofer-Gal]

If anyone has the error because of removing @pnp/spfx-controls-react from the project, like I had.
The issue is that uninstall @pnp/spfx-controls-react does not remove the line in config.json for property TestVanilaWebPartStrings":
"ControlStrings": "node_modules/@pnp/spfx-controls-react/lib/loc/{locale}.js"

once I removed it, it worked fine.

[lafe]

I'm going to close this issue as there is no error in the SPFx itself.

I would disagree with that statement. The main issue is that the build fails but you only get "[Object object]" as the error message. Failing a build is okay, but at least output why it failed...

[tandrasi]

I'm going to close this issue as there is no error in the SPFx itself.

I would disagree with that statement. The main issue is that the build fails but you only get "[Object object]" as the error message. Failing a build is okay, but at least output why it failed...

Agree. I updated PnP SPFx controls to 3.17.1 and I still get one instance of the error (mind you, before I got 6). Control Strings are all correct etc..., but I still don't know what the culprit is in my case. Yes, I could try v4 (beta) but I'm in production.

[stevebeauge]

@AJIXuMuK Please reopen the issue. It's a huge issue to not have error messages if anything goes wrong in the build chain. The actual issue here is having a [Object object] error message.
Most of us here have different issue that can't be understand with such message. And this should be corrected by spfx team.

thanks

[AJIXuMuK]

@stevebeauge Please open a separate issue to address incorrect messaging on errors.

[stevebeauge]

This is exactly the statement of this issue

SPFx 1.19.0 - Error during build with [object Object] errors that didn't happen in previous versions

[JakeStanger]

No idea why this was closed. The fact that we get [object Object] instead of an error in the SPFx build tools provided by the SPFx project template due to a bug in the SPFx build pipeline is most definitely an SPFx issue.

[LastGunslinger]

No idea why this was closed. The fact that we get [object Object] instead of an error in the SPFx build tools provided by the SPFx project template due to a bug in the SPFx build pipeline is most definitely an SPFx issue.

I am in 100% agreement with this. I spent hours trying to debug a simple issue that was just an incorrect import statement, but I had no idea what or where the issue was at the time because all the build command gave me was this annoying "[object Object]" response. This is ABSOLUTELY an issue with the SPFx build tools that needs to be addressed. The fact that it is emitting errors that developers have no way to parse is inexcusable.

[tandrasi]

@JakeStanger and @LastGunslinger, while I feel the same way, at least the new bug created has been labelled accordingly ("bug-confirmed") by team members: #9834.

[jtlivio]

Please See My Conclusions, in my opinion not a Bug @AJIXuMuK nothing to do with the React or Property Controls, thank you all, good point @RedGlow

[JakeStanger]

Your blog post shows the same issue & workarounds as this thread, and concludes by suggesting users should manually patch a file in node_modules to work around this. Obviously that's not a permanent solution. I'm interested how you don't see that to be a bug?

[jtlivio]

@JakeStanger I understand your point of view and appreciate your observation. Based on my tests and opinion, the problem lies in the developer’s code. Therefore, I’m not suggesting that the error message without any compiler suggestion is acceptable. Most of the time, debugging as @StfBauer suggested, results in the same error. However, I can review the code and fix the issues without altering the Webpack configuration. That’s why, for me, it’s a behavior that needs improvement, not a bug. Different perspectives can be good in any life situation.

Read my Article Here, but read between the lines.

[tlandicho]

As @RedGlow suggested, by adding more information to the debug statement, I was able to determine that my problem was with my JQuery dependency.