Web Part Missing in Toolbox After Running Gulp Serve

[Sucharita993]

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

• SPFx version - 1.18.2
• Browser version - latest

Describe the bug / error

After running the gulp serve command to launch an existing SPFx project locally, the web part is not appearing in the toolbox. It was functioning perfectly until December 11th, but the issue began on December 12th.

Steps to reproduce

1. Take a sample spfx project
2. give gulp serve in cmd

Expected behavior

Expected the webpart to be listed under local category.

[Sucharita993]

Sharing screenshots of DevTools console errors.

[AJIXuMuK]

@Sucharita993 - thank you for reporting the issue.
We have identified the problem and will be working on the fix.

In a meanwhile, as a workaround, copy all the generated files from temp to temp/build folder.
It should unblock you while we're working on the fix

[AJIXuMuK]

Here is the gulptask you can add to your gulpfile.js to automatically copy the files:

// add these after const build = require('@microsoft/sp-build-web');
const fs = require('fs');
const path = require('path');

// Insert this code before build.initialize(require('gulp'));
const copyTask = build.subTask('copy-to-build', function (gulp, buildOptions, done) {
  const srcFolder = './temp';
  const destFolder = './temp/build';
  // Check if the destination folder exists, if not, create it
  if (!fs.existsSync(destFolder)) {
    fs.mkdirSync(destFolder, { recursive: true });
}

// Copy files from srcFolder to destFolder, excluding destFolder itself
return gulp.src([path.join(srcFolder, '**/*'), '!' + destFolder])
  .pipe(gulp.dest(destFolder));
});

build.rig.addPostBundleTask(copyTask);

[Ashlesha-MSFT]

Hello @Sucharita993,
Thank you for bringing this issue to our attention. We will look into it and get back to you shortly.

[Ashlesha-MSFT]

@Sucharita993,
Could you please confirm if everything looks good on your end as well? If so, can we go ahead and close the issue?

[chr-sad]

I just tried to test the new SPFx 1.21-rc.0 release with a newly scaffolded webpart but I think, this issue still exists. I still get the warning message, but when I close it, I can find the webpart in the list and add it to the workbench. @AJIXuMuK should we still update the gulpfile.js manually?

I do not know if it is releated, but it seems, that the *.scss is not loaded as well. (e.g. HelloWorld.module.scss). But it could be an issue with the RC as well.

[jaimin1502]

I also facing the same issue . webpart is not loading in toolbox.

[richaB-gif]

I am facing same issue. I am using node version 18.17.1 and spfx version is 1.20.0 with this capability it is not working in toolbox.
Sharing screenshots of DevTools console errors.

[piekenpuil]

just created a brand new 1.21 SPFX project. ran gulp serve, and I got the same warning. So, still an issue.

[thechriskent]

Also just tried a vanilla webpart (no framework) and am seeing the same problem.

SPFx: 1.21.0
Node: 22.15.0

As you can see, the webpart is already added to the workbench at this point, but will still show this warning on refresh. Dismissing this allows you to select the webpart after at least one refresh after the first time you get the warning.

You can also see styles are not being applied. Looking in the style module you can see the postfix being added:

But when you check the styles in the browser you can see they've got an extra postfix:

Adding @AJIXuMuK's gulp script from above seemed to have no effect. But that's assuming I did it right.

Rolling back to SPFx 1.20.0 (Node 18.20.3) worked perfectly. Looks like we're gonna need an SPFx 1.21.1

[grantjenkins]

I'm also seeing the same issue. I logged a bug (#10207) which now has a reference to this one.

[petkir]

I was playing around to avoid the multiple hashes:

Webpack config adds hashes, and this is too much.

gulpfile.js

build.configureWebpack.mergeConfig({

  additionalConfiguration: (generatedConfiguration) => {
    // Modify CSS Modules loader configuration
 
    if (generatedConfiguration.module && generatedConfiguration.module.rules) {
      for (const rule of generatedConfiguration.module.rules) {
        if (rule.use && rule.use[0] && rule.use[0].loader.includes('css-loader') && rule.use[0].options.generateCssClassName) {
          console.log('Rule Test:'+ rule.test);
          console.log('Rule Loader:'+ rule.use[0].loader);
          console.log('Rule generateCssClassName ori:'+ rule.use[0].options.generateCssClassName);

          rule.use[0].options.generateCssClassName = (existingClassName, cssFilename, cssContent)=>{
            return `${existingClassName}`;
        };
          
        }
      }
    }
      
    return generatedConfiguration;
  }
    
});

Output:

[22:04:24] Starting subtask 'configure-webpack'...
Rule Test:/\.module(?:\.scss)?\.css$/i
Rule Loader:/Users/pkirschner/github/petkir/pnp/sp-dev-fx-webparts/samples/react-image-editor/node_modules/@microsoft/sp-css-loader
Rule generateCssClassName:(existingClassName, cssFilename, cssContent)=>{
    let hash = cssHashCache.get(cssFilename);
    if (!hash) {
        hash = _crypto.createHmac('sha1', cssFilename).update(cssContent).digest('hex').substring(0, 8);
        cssHashCache.set(cssFilename, hash);
    }
    return `${existingClassName}_${hash}`;
}
[22:04:24] Finished subtask 'configure-webpack' after 137 ms

After that, it looks as expected:

@thechriskent if you have time can you validate my solution?
i tested it on 3 Solutions, but works on my machine is not the right way. 🙈

and yes the code is ugly

https://github.com/pnp/sp-dev-fx-webparts/pull/5464/files#diff-fd6cc528dbb87bac00556db8887d9a66f3acbd40a867d3ae5c1b90f876e63d3c

[thechriskent]

I can confirm that adopting @petkir's gulp file changes fixes the issue for me with the vanilla webpart. In fact, I'm not seeing either the webpart missing error dialog or the missing styles. Nice!

Regardless, I'm sticking with 1.20 for now. Teaching a workshop next week and having them add a temporary work around isn't going to be a good experience. Fortunately, seems like a 1.21.1 may not be such a hard ask.

[VesaJuvonen]

This is now a combination of two issues unfortunately - so providing an update for both of them.

• Web part missing in Toolbox - this is a false message caused by a bug in the online workbench - message is not correct, it's caused by a wrongly implemented double loading of the local host assets - web part does exist in the toolbox
• Styling issue with the hashes will be addressed with 1.21.1 update, currently planned to get published on Friday 2nd of May - but could be delayed until early next week

Thanks everyone for your invaluable input on the issues. This will help others in the ecosystem to know about the issues and it helps engineering to address regressions and bugs as fast as possible.

Sorry for the inconvenience - fixes incoming.

[VesaJuvonen]

Specifically for the styling issues - we have now pushed 1.21.1 to address that. Release notes at https://learn.microsoft.com/en-us/sharepoint/dev/spfx/release-1.21.1

Workbench misleading warning is fixed and checked in to server side code. Will start rolling to production soon.

[petkir]

1.21.1 is working as expected 👍

[muges01]

I'm using Node 22.15.0 and SPFx 1.21.1 but still experiencing the issue.

[muges01]

1.21.1 is working as expected! Thank you.