The TypeScript for SPFX is so out of date.... ( 2.4 ) really MS

[darkriderdesign]

How are we expected to use SPFX with all of the vulnerabilities, in the out of date versions of open source JS. Microsoft if your going to go open source.... then go open source and keep up. bottom line.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: c43fab8f-85bf-e577-317b-a71dada5c865
• Version Independent ID: 4d041f90-2cc7-ed20-c007-d2a36f9c7c7b
• Content: Update SharePoint Framework packages
• Content Source: docs/spfx/toolchain/update-latest-packages.md
• Product: sharepoint
• GitHub Login: @spdevdocs
• Microsoft Alias: spdevdocs

[CPritch]

Second this a thousand times. We have had to fight the framework constantly due to typescript versioning issues. React 16 is still not sorted too!

[RoelVB]

@CPritch See this article. They are upgrading Sharepoint Online to React 16.

Unfortunately the old TypeScript version with SPFx still remains.

[lafe]

To make matters worse: If you have to develop for SharePoint 2019, the version is frozen in time and you have to use really old versions. Currently, it's only semi-bad but it will get much, much worse over the lifecycle of SharePoint 2019 if Microsoft does not invest in updating the tooling for SPFx.

[CPritch]

To make matters worse: If you have to develop for SharePoint 2019, the version is frozen in time and you have to use really old versions. Currently, it's only semi-bad but it will get much, much worse over the lifecycle of SharePoint 2019 if Microsoft does not invest in updating the tooling for SPFx.

We've had a response that MSFT is NOT updating SharePoint 2019's SPFx version until the next major content update. Ridiculous, why is the Enterprise version of the software supposed to remain out of step?

[andrewconnell]

This isn't intended to be excuses, but to clarify some points made in this thread. If you'd like to request MSFT change their stance (such as not updating on-prem SPFx in SP2016 & SP2019), that falls into a feature request which would best be submitted to user voice: https://aka.ms/sp-dev-uservoice.

I don't see anything actionable in this issue to flag as a bug or a question, so I will close the issue after responding.

@darkriderdesign said:

How are we expected to use SPFX with all of the vulnerabilities, in the out of date versions of open source JS.

Fair point that some existing packages leveraged in the build toolchain are old, such as TypeScript (v2.4 vs. the current v3.x) and webpack (v3.x vs the current v4.x) in the current in SPFx release (v1.7.1), to be clear the only thing you deploy to your SharePoint environment is a JavaScript bundle that includes YOUR code, not code from other packages. None of the dependencies in a base package are shipped with your deployment... the only thing in the resulting JS bundle is your code.

If you elect to use other 3rd party libraries such as lodash, underscore, jquery, jquery plugins, moment, etc, the versions used are managed by you and can be deployed in the bundle or referenced from a CDN. IOW, you have full control here.

@CPritch said:

We've had a response that MSFT is NOT updating SharePoint 2019's SPFx version until the next major content update. Ridiculous, why is the Enterprise version of the software supposed to remain out of step?!

Microsoft has said for many years and two SharePoint releases now that the focus is to build for SharePoint Online first, then to have the on-premises version of SharePoint to be a snapshot from a point in time from what's in SPO. This has been true for both SharePoint Server 2016 & SharePoint Server 2019. Going back to SharePoint 2013, they've been pretty clear that the recommendation is to move to SharePoint Online where they can not just innovate quicker, but to also address vulnerabilities much quicker as well.

Again... this isn't meant to be an excuse. There's just nothing actionable in this issue hence why I'm closing it.

With all that being said...

Personally, I've been annoyed with the toolchain as I too want to use the latest version of React in production, leverage the best features & performance improvements from the latest versions of TypeScript & webpack in my builds, but I can't find fault with the on-prem stance. They've been more than clear about their plans & goals for well over 5 years... you could argue nearly 7 going back to their public statements at the SharePoint Conference in 2012 where they initially stated, but later rolled back, that SharePoint 2013 would be the last on-prem version.

[darkriderdesign]

The point of my comment wasn't to express, to "not" use SPFX the point was to express, that the community needs quicker updates. That's all... I love working in the new SPFX framework. But when I go to incorporate something from NPM and what I'm trying to incorporate is 3 versions newer in the code base it just raises eyebrows. So again, I'm glad the thread is being closed, and Microsoft is doing a great job, keep up the good work.

Thanks,

Darkriderdesign

[CPritch]

@darkriderdesign

Second this a thousand times. Apologies for my rant as it was not fair. SPFx has revolutionised what we can produce and the time we can do it in. I am very excited to see how the platform progresses.

I truly believe that this is the future of the modern intranet and along with Teams we're seeing all the puzzle pieces fall into place for the vision MS has here.

[andrewconnell]

BTW... take a look at SPFx v1.8.0. Includes TypeScript v2.7.2, React v16.7 (but be aware of #3605) & Fabric React v6.156.

[lafe]

BTW... take a look at SPFx v1.8.0. Includes TypeScript v2.7.2, React v16.7 (but be aware of #3605) & Fabric React v6.156.

But that does not remove the issues that exist on SharePoint 2019 as this is fixed on 1.4.1 with lots of issues in the corresponding tooling. In my opinion, it is one thing to freeze the platform but a different thing to also freeze the tooling required to build stuff for the platform. In the past, it was possible to use the newest Visual Studio Version and newest C# version to write Full Trust Solutions even for pretty old SharePoint versions (I can still write a Full Trust Solution for SharePoint 2013 with VS 2017 and C# 7.3...). The same should be true for SharePoint on premises even though the platform will not get any new Features.

[ThomasDeutsch]

The SPFX team created a tooling that makes it very easy for a sharepoint developer to get started.
While the first steps are achieved without great effort, it becomes clear that "making things easy" comes at a great cost in the long run.
The tooling is very interwoven and full of dependencies.
From the first moment of setting up a SPFX Project, i already lost a great amount of control and flexiblity to move things forward during the next months of my project.
Sorry, this is not very constructive.

I would love to see some documentation on how to setup a minimal project template. Without ANY yeoman and without any advanded dependencies or build-tasks. And then let the some develpers start from there. And maybe the SPFX-team can discover that there is real value in a simple solution.

[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