Sp-dev-docs: office-ui-fabric-react version mismatch in generator template

[deanbot]

Category

• [x] Bug

Describe the bug

@microsoft/sp* packages (i.e. @microsoft/sp-property-pane) use office-ui-fabric-react 7.59.0 yet the generator still uses 6.189.2

With https://github.com/SharePoint/sp-dev-fx-controls-react/issues/256 pending, I've got 3 versions of office-ui-fabric-react that need to be installed - really slows things down from a fresh install perspective.

Steps to reproduce

1. yo @microsoft/sharepoint

2. note what's being installed or analyze package-lock or shrinkwrap.yaml, etc

If that doesn't show 6.189.2 + 7.59.0 in use then this is possibly pnpm related.

Expected behavior

office-ui-fabric-react package provided by yeoman generator in step with @microsoft/sp-* packages.

Developer environment

• OS: Windows 10
• Framework: node.js v10.16.3,
• Tooling: VS Code, SPFx v1.10.0, pnpm v4.9.3, rush v5.20

[msft-github-bot]

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

[deanbot]

I was able to update the ouifr package version manually in my web part package.json file(s) (from v6 to v7).

In my code base the biggest v7 compat issue was that they dropped autobind (https://github.com/OfficeDev/office-ui-fabric-react/issues/9717). 2nd biggest was 'onChanged' deprecated in favor of 'onChange' for various text inputs.

[andrewconnell]

The SPFx generator may update that when the next version is released, but not clear as to what the "problem" is?

[deanbot]

@andrewconnell the assumption here is that the verison of ouifr added by the generator should be the same as other dependencies added by the generator. I.e., @microsfot/sp-*@1.10.0 packages use 7.59.0, therefore that should be the ouifr version added by the generator. That this is not the case is presumably an oversight?

As far as compatibility goes, I don't think it matters in this case since 6.X and 7.X both use the same react versions - this would presumably matter if this wasn't the case. It does matter if you care about downloading unneeded dependencies. This matters to me because my pc takes a particularly long time to install each ouifr version.

[andrewconnell]

If the MSFT dependencies are using a specific version, common sense would imply that version is supported in SPO & the SPFx generator just hasn't been updated since that changed. So why not just upgrade your project to use the v7?

I'd assume the v1.next version of the SPFx generator would get updated to use the supported version of OUIRF.

[deanbot]

I'll leave the issue open until then since it's an issue with @microsoft/[email protected] :)

In my humble opinion, the version in the generator should have changed when the version in the msft packages changed: 1.10. If you tell me though that my assumption is wrong and the generator shouldn't change the package version to match @microsoft/sp- packages I'll gladly close the issue.

Thanks!

[andrewconnell]

@deanbot said

In my humble opinion, the version in the generator should have changed when the version in the msft packages changed: 1.10. If you tell me though that my assumption is wrong and the generator shouldn't change the package version to match @microsoft/sp- packages I'll gladly close the issue.

Your assumption is wrong :).

OK... now let me explain...

MSFT has to support v6 because when SPFx v1.10 was released, OUIFR v7 had issues with some back-compat v6 components. If the generator changed to v7, that implies that previous OUIRF versions wouldn't be supported in SPFx v1.10 (which isn't the case). The OUIFR guidance changed a long time ago that your package should include the version of OUIFR that you're using, and in this case, that's OUIRF v6.

The dependent packages that reference OUIFR v7 are correct... any back compat issues are addressed in the components they are using, such as the property pane controls.

[deanbot]

Does it imply that? I didn't know that. Okay then! So far I'm not seeing anything too major with v7 (in case anyone finds this).

[andrewconnell]

@deanbot

One thing to clarify... when I said "common sense would imply that version is supported in SPO & the SPFx generator just hasn't been updated since that changed.", that's my opinion. That's not me restating what MSFT said.

What I said in this comment is paraphrasing a discussion I had with SP engineering based on this thread

[deanbot]

That's how I read it.

[msft-github-bot]

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues