SPFx 1.22.0-rc.0 - Community Feedback

[nick-pape]

Please use this post as an aggregated discussion place for ideas and feedback that don't necessarily warrant an Issue ticket.

Changes in the RC

• We bring back the lib-commonjs build output, and switch the lib/ back to ESM (to support webpack chunking). The lib-commonjs exists as a target for jest tests.
• Fixes an issue where typescript version is overwritten during eject.
• Fixes incorrect @rushstack/heft peer dependency issue.

Other notes

• We are aware that ESLint 8 is deprecated. We've upgraded our internal repository to use ESLint 9. SPFx 1.23 with Heft will include the ESLint 9 upgrade; however, the current plan is that the Gulp-based toolchain will remain on ESLint 8.
• SASS Sourcemaps are not currently supported by Heft SASS plugin at this time. We will work to get this added to Heft, and it will be included in 1.23 release.

Prior feedback posts:

• 1.22.0-beta.5
• 1.22.0-beta.4
• 1.22.0-beta.3

[andrewconnell]

TL;DR: Move eslint config ▶ spfx-web-build-rig

Since we now have a build configuration refactored into a rig, with its own configurations for things like:

• ./tsconfig.json extending ▶ *./node_modules/@microsoft/spfx-web-build-rig/profiles/default/tsconfig-base.json
• ./config/sass.json extending ▶ @microsoft/spfx-web-build-rig/profiles/default/config/sass.json**
• ./config/typescript.json extending ▶ @microsoft/spfx-web-build-rig/profiles/default/config/typescript.json

... how about new SPFx projects use the same approach for ./.eslintrc.js?

proposal ▶ move ESLint config to SPFx rig

1. copy ./.eslintrc.js ▶ *./node_modules/@microsoft/spfx-web-build-rig/profiles/default/.eslintrc.js

   not very important, but it could go in the config subfolder with other heft plugin configurations...

2. update existing ./.eslintrc.js config to extend from rig's config so it only contains:

   require('@rushstack/eslint-config/patch/modern-module-resolution');
   module.exports = {
     extends: [./node_modules/@microsoft/spfx-web-build-rig/profiles/default/.eslintrc.js],
     parserOptions: { tsconfigRootDir: __dirname }
   };

benefits

• future updates to the rig package update the ESLint rules without requiring someone to update the actual rules in their existing projects
• customers can apply their own overrides array property to the existing rules...
• ... and future rig updates won't impact their overrides

Inspired by my original article: How to set up reusable ESLint configs for SharePoint Framework (SPFx) projects

[HolgerWurbs]

I noticed hot update not working because webpack serve tries to connect to port 8080. There's also some error spam about it in the console. I could fix it by adding a spfx-customize-webpack.js to the config folder with the following content:

module.exports = function (webpackConfiguration) {
  if (webpackConfiguration.devServer) {
    webpackConfiguration.devServer.client = {
      webSocketURL: {        
        hostname: webpackConfiguration.devServer.host || 'localhost',
        port: webpackConfiguration.devServer.port,
        protocol: 'wss'
      }
    };
  }
  return webpackConfiguration;
};

[thechriskent]

The default README should have it's Microsoft 365 tenant link updated to not include the language code.

It's currently:

- [Microsoft 365 tenant](https://docs.microsoft.com/en-us/sharepoint/dev/spfx/set-up-your-developer-tenant)

It'd be better if it were:

- [Microsoft 365 tenant](https://docs.microsoft.com/sharepoint/dev/spfx/set-up-your-developer-tenant)

Ideally, it would be an aka.ms link pointed at https://learn.microsoft.com/sharepoint/dev/spfx/set-up-your-developer-tenant

[thechriskent]

When running npm run start the first time, I was given a helpful warning about the dev certificate. But the experience of it immediately opening a separate terminal and prompting me for admin credentials and then my password for a sudo command was quite jarring.

I think instead of automatically running the trust-dev-cert stuff, the user should be told about the issue and either told to run the command as part of a failure message or even better be asked if they want to install/update the dev-cert. It's a small thing, but I think you'll end up with less concerned developers - especially since this will be part of a first run experience.

[thechriskent]

Creating a production package is going to trip up devs.

We've placed the gulp equivalencies in the 2nd article under the Heft-based toolchain set of docs. In there, we call out that --ship has been replaced with --production:

https://learn.microsoft.com/en-us/sharepoint/dev/spfx/toolchain/customize-heft-toolchain-overview#heft-actions-and-legacy-gulp-tasks

Lame that we changed it from 'ship' to 'production', but I'm guessing that's a heft thing and just how it is. But how it is added to the command has changed since we're now using npm scripts rather than gulp tasks. I think most devs will try and do this:

npm run package-solution --production

Which will be very confusing to them when it looks like this:

The documentation should be updated to point out that the command is actually:

npm run package-solution -- --production

Additionally, I think adding an additional script would make things even easier:

It's less to type, it's easy to find, and easier to understand.

[andrewconnell]

You don't have to use the NPM scripts.

@thechriskent said:

The documentation should be updated to point out that the command is actually:

npm run package-solution -- --production

That -- is only applicable if you're using NPM scripts. The warning you're seeing is coming from Heft, not from anything specific to SPFx... so that's not something SPFx can address.

This is a slippery slope because, taken to its logical conclusion, you'd have to create an NPM script for every argument combination (see build-watch). And when you want to see what commands are available to you, the following won't match the npm script name:

heft --help

Because the above will only list package-solution & pacakge-solution-watch. Also, the normal CLI commands start to get useless for baked in docs, like heft pacakge-solution -h to see all the arguments.

Personally, I prefer to install Heft globally and run the commands just like you do with the gulp-cli in pre-v1.22, as I explain here: Understanding the Heft-based toolchain (how it works): Heft architectural concepts

BTW, there's an error in the docs talking about how ot install heft globally... doc fix in process... PR pending #10499. Short story: because heft is a scoped package, you need the whole name: @rushstack/heft.

[thechriskent]

What is the deploy script? The docs refer to it as dev-deploy and mention that it deploys the assets to a test CDN.

So, what's this command trying to do and how is it different than deploy-azure-storage?

I think we need better guidance on these. Having a script called deploy seems like it would indicate something closer to uploading the packaged solution to an app catalog. This appears to be something dev related, but what that is isn't answered in the docs

[andrewconnell]

dev-deploy is mentioned below this table as a footer.

@thechriskent said:

This appears to be something dev-related, but what that is isn't answered in the docs

Hmmm... I intended to answer that in the footer, but it's not clear enough. I'll take that as an optmization task... but the short story:

The deploy-azure-storage actually deploys your assets (JS bundle, localization file, etc) that you aren't including in the *.sppkg to be provisioned to the ClientSideAssets library. That's used AFTER packaging (ie: heft package-solution --production). IOW, it acts like the same command we had in the gulp-based toolchain.

The dev-deploy is new... it does the following:

1. processes and uploads the SPFx manifests, components & deps
2. gen's a manifest.js file wiht all component metadata
3. creates a debug/test URL for SPO workbench testing

Basically, when you run it, it gets an azure storage container where you want to test your project with your own CDN. it automatically uploads a dynamically gen'd folder (timestamp/hash name) but preserves using the SAS token auth for the container

It then outputs the testing URL with query params, saves the metadata to a local JSON file (dev-deploy-metadata.json

[DonKirkham]

I'm probably missing it, but looking at the documentation, the "Set up development environment" page (https://learn.microsoft.com/en-us/sharepoint/dev/spfx/set-up-your-development-environment) has all of the legacy instructions with no mention of Heft. The Heft toolchain section does not talk about setting up the environment either. Is there an "unpublished" update to that page?

[VesaJuvonen]

We are still in Release Candidate side - so the @ current and latest for production is 1.21 with Gulp. This page will be updated as part of the general availability doc updates, but not before that.

Only difference is that you can install Heft globally - so new call to include is npm install -g @rushstack/heft