Skip to content

Adds support for SPFx v1.22.0-rc.0. Closes #6974#7046

Closed
waldekmastykarz wants to merge 3 commits intopnp:mainfrom
waldekmastykarz:spfx-1220-rc0
Closed

Adds support for SPFx v1.22.0-rc.0. Closes #6974#7046
waldekmastykarz wants to merge 3 commits intopnp:mainfrom
waldekmastykarz:spfx-1220-rc0

Conversation

@waldekmastykarz
Copy link
Copy Markdown
Member

@waldekmastykarz waldekmastykarz commented Nov 22, 2025

Adds support for SPFx v1.22.0-rc.0. Closes #6974

Adam-it
Adam-it requested changes Nov 23, 2025
View reviewed changes
Copy link
Copy Markdown
Member

@Adam-it Adam-it left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@waldekmastykarz Amazing work so far 👏
We are on the right track, but I noticed a few things we need to sort out before we proceed.

Comment thread src/m365/spfx/commands/spfx-doctor.ts Outdated
Comment thread ...project/project-upgrade/rules/FN025003_ESLINTRCJS_rushstack_pair_react_dom_render_unmount.ts
Comment thread src/m365/spfx/commands/project/project-upgrade/upgrade-1.22.0-rc.0.ts Outdated
Comment thread src/m365/spfx/commands/project/project-upgrade/upgrade-1.22.0-rc.0.ts
@Adam-it Adam-it marked this pull request as draft November 23, 2025 00:17
@waldekmastykarz waldekmastykarz marked this pull request as ready for review November 23, 2025 11:11
Adam-it
Adam-it requested changes Nov 24, 2025
View reviewed changes
Copy link
Copy Markdown
Member

@Adam-it Adam-it left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@waldekmastykarz in general I think it is ok. Just wanted to recheck with you one last thing before we merge

So when testing this change, I created a fresh new SPFx 1.22 webpart and in the yo-rc.json I only manually changed the version from 1.22-rc0 to 1.21.0, and then I ran m365 spfx project upgrade --preview.
I expected I would just get a single guide to update the version in the yo-rc file but as a result I got this

image

and this is a bit strange IMO
if we look for the test 1.22-rc0 webpart project package.json
src/m365/spfx/commands/project/test-projects/spfx-1220-rc.0-webpart-react/package.json

  1. It, by default, does not have a dependency to @microsoft/[email protected] so why should we add it now?
  2. also the command outputs to install [email protected] and [email protected] but we do have them but with just ~ before the version. This might be very confusing.
  3. also it suggest to install @microsoft/[email protected] I think this is a bug

could we recheck the above before we proceed

@Adam-it Adam-it marked this pull request as draft November 24, 2025 21:00
@waldekmastykarz
Copy link
Copy Markdown
Member Author

waldekmastykarz commented Nov 26, 2025

Good catch and sorry for trouble. I'll get it fixed asap. I appreciate your review

@waldekmastykarz
Copy link
Copy Markdown
Member Author

waldekmastykarz commented Nov 29, 2025

I had a quick look. Here's what I've found:

  • suggestion to install @microsoft/[email protected] comes from the fact that you're upgrading from 1.21.0 to 1.22.0-rc.0. So the upgrade path is 1.21.0 > 1.21.1 > 1.22.0.rc0. The package version gets bumped in 1.21.1 but then it's removed altogether. This is a known issue/limitation that we've had for quite some time: Bug: superseding rules works incorrectly #2593.
  • @microsoft/[email protected] seems like there's a bug in the rule, where its severity is defined as optional but the package isn't, so it always comes up in the report. I think we should mark the package as optional so that the rules pops up only if the package is installed
  • re versions with ~: that's tricky. We had this issue in the past. Let me see if we can improve handling comparisons of ranges

@waldekmastykarz
Copy link
Copy Markdown
Member Author

waldekmastykarz commented Nov 29, 2025

It seems like handling ranges (~) is possible but it will be a somehow larger refactoring because until now we assumed erroneous behavior (yielding findings even if a range matches a version). To not block the release, I suggest we use what we have for now, and address the fix in a separate issue.

@waldekmastykarz waldekmastykarz marked this pull request as ready for review November 29, 2025 11:27
Adam-it
Adam-it approved these changes Nov 29, 2025
View reviewed changes
Copy link
Copy Markdown
Member

@Adam-it Adam-it left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

all good 👍
Lets ship it 🚀

@Adam-it
Copy link
Copy Markdown
Member

Adam-it commented Nov 29, 2025

It seems like handling ranges (~) is possible but it will be a somehow larger refactoring because until now we assumed erroneous behavior (yielding findings even if a range matches a version). To not block the release, I suggest we use what we have for now, and address the fix in a separate issue.

gottcha, would you like to create an issue for that?

@Adam-it
Copy link
Copy Markdown
Member

Adam-it commented Nov 29, 2025

ready to merge 🚀

@Adam-it
Copy link
Copy Markdown
Member

Adam-it commented Nov 29, 2025

merged 🚀

@Adam-it Adam-it closed this Nov 29, 2025
@waldekmastykarz waldekmastykarz mentioned this pull request Dec 1, 2025
Closed
@waldekmastykarz waldekmastykarz deleted the spfx-1220-rc0 branch January 3, 2026 11:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@Adam-it Adam-it Adam-it approved these changes

Assignees

No one assigned

Labels

pr-merged

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Add support for SPFx v1.22.0-rc.0

2 participants

@waldekmastykarz @Adam-it