SPFx 1.22.0-beta.3 - Feedback

[Adam Wójcik (Adam-it)]

Follow up to #10437
I want to open this discussion to gather some feedback regarding SPFx 1.22.0 -beta.3

[Nick Pape (nick-pape)]

Thanks @Adam-it , it is my mistake for not seeing these earlier, we were triaging out of the "Issues" tab.

Super awesome to see the reduction of vulnerabilities from 90 to 19 🤩👏.

The goal is to get to 0 by the 1.22 GA.

Of course, this is an ongoing process as new vulnerabilities are discovered and reported all the time. And some (places where we directly depend on outdated versions) are easier to fix than others (places where the vulnerability is coming from deep within dependency chain and requires fixes to non-Microsoft OSS packages).

If we ship with known npm audit issues, we'll be sure to publish reasoning.

[Adam Wójcik (Adam-it)]

This is AWESOME

[Nick Pape (nick-pape)]

Why in the package.json we need "overrides": { "@rushstack/heft": "0.74.3" } ?

This is just to ensure consistency of the peer dependency. Rush Stack lives in a different repo than SPFx core, there's a small delta between them, and NPM will try to install latest Rush Stack versions.

I actually think this is a byproduct of how npm handles "^" dependencies for <1.0 versions, and we may be able to remove after the Heft 1.0.

Also I think Heft is already 1.0.0, I think it would better to use this version of package in the scaffolded project as well

Yes, it is! We are very excited about this. The next beta will utilize Heft 1.0.

[Adam Wójcik (Adam-it)]

gotcha

[Nick Pape (nick-pape)]

npm publish script which would be a combination of heft build --clean && heft package-solution --production.

This would be pretty trivial to add. We will consider it. We'll likely add this as a top-level heft command. Note: heft commands can be easily added using config/heft.json.

[Adam Wójcik (Adam-it)]

not sure if additional heft task is needed for that. But I am fine with any option

[Nick Pape (nick-pape)]

I wonder would it make more sense if the npm script package-solution would default to production package so run heft package-solution --production

Ack. We will look at this. By default everything runs non-production for consistency. It could make sense to combine this with the above in an all-encompassing heft finalize (or similar) command that does everything (build, test, package) in production mode. Open to more discussion here.

[Adam Wójcik (Adam-it)]

good idea 👍

[Nick Pape (nick-pape)]

we have a useGulp: false property. What is the point of that?

We track if the solution was created with gulp or heft, as you can't mix the two.

in the past version the 'sdkVersions' had microsoft-graph-client and teams-js specified. Now this property is empty. Is this ok?

We aren't using these are the moment. But for consistency, I'll take a look at this.

Also, in the future, we're looking at improving the .yo-rc.json -- turning it into something more akin to a "scaffolding audit log" than just a random (mostly unused) property bag. Also open to ideas here.

[Adam Wójcik (Adam-it)]

gotcha.. thanks for the reply

[Nick Pape (nick-pape)]

Also, I noticed the newly scaffolded projects are missing launch.json file to start debugging from VS Code

We'll double check this and bring it back if necessary.

[Adam Wójcik (Adam-it)]

not sure if it was used TBH.
I did not use it that much during my work, but still this was some option that did exist in previous version of SPFx

[Nick Pape (nick-pape)]

Looks like eject mode might not be working properly in Beta 3, this will be fixed in Beta 4.

[Adam Wójcik (Adam-it)]

Closing this one as a new beta was released, and we may continue the discussion on #10448