Sp-dev-docs: Updating existing projects to SPFx 1.4

[shaipetel]

Category

• [x] Question
• [ ] Typo
• [x] Bug
• [ ] Additional article idea

Expected or Desired Behavior

I should be able to update my packages to 1.4 release in an existing project and get all new features without rebuilding the project

Observed Behavior

SPFx 1.4 introduces several new features, like for example a new property in package-solution.json that allows to keep resources in the sppkg file and deploy automatically to a CDN.
After following the guides to update to 1.4 (which takes HOURS, and after many errors was finally completed) and updating my yo generator as well, I found that existing projects now are lacking some of these settings, while newly created projects have them.

I know I can copy what I want from a new project, or like many recommend: move my code into a new project built with that version. But neither offer a truly solid viable solution for getting updates.
This makes for a very sad update experience for developers... not to mention the waste of time having to sit at the keyboard for hours typing command after command to get updates installed, reading million lines of code looking through warnings and errors...

What is the proper way to get updates into an existing project, including all new features/flags/settings?
I remember before GA we were told we won't have to move our code to a new project every time a new version is released. So, am I missing something or is this really the only way to get SPFx updates?

Steps to Reproduce

Build SPFx project in an older version.
Upgrade your packages and yo generator to the latest.
The project settings are very different than those of a new project created in the latest version.

[patmill]

Hey @shaipetel - going through some old bugs that have slipped. Not sure I fully understand your request though. Are there differences between your package.json files and the new files, or that the baseline webpart code that the generator has changed, or something else?

In general, we don't try and upgrade any existing projects. I believe that some of the people working Office 365 cli folks (hi @waldekmastykarz and @andrewconnell ) are thinking of developing something along these lines, although I don't think anyone would want to start messing with source files - that seems like a risky proposition.

[shaipetel]

Hey, I’m not suggesting you deal with my code and fix or change my code.

I’m suggesting that when upgrading a version you will upgrade and modify ALL project/framework generated files to match the new scheme.

I did get some files updates but like I mentioned- most project supporting files (not code files) remained in the old format and are missing some parameters that a newly created project will have.

Simply create an old version project, and upgrade it. Then compare it to a project created in latest - you will find lots of differences.

[patmill]

Let's try a different approach here. We don't upgrade your projects - we normally suggest "update your package.json to point to the new packages, nuke your node_modules directory and run npm install".

What differences are you referring to in particular? Things in package.json? contents of node_modules? lint configs? TS configs?

In general, touching those things is not something we would want to do generally.

Or is this issue more of a "here are the steps you might want to consider"?

[shaipetel]

more specifically, as I recall - all/most JSON files under the config folder were left untouched.
In a newer built project they either have a different schema altogether, or just have a few more flags and settings available.

also other config json files in other folders - same thing.

Imagine a classic VS project. you open project properties and see X features.
You install an update to the VS, or to VS tools for SharePoint which add 5 more options in the properties.

now - imagine you go to project properties of a project that was created in older version, and that these 5 new properties are not showing up and you can't use/select them! Instead, you ask the developer to manually add these features to the config file, but how would the developer even know these 5 new properties were added?

Does that make more sense? I think this is rooted in the lack of designers and keeping it all as simple json files. Its not a bad thing necessarily but if you don't expand it when installing updates that becomes a problem IMHO.

Thanks!

[frankchen76]

I like to see the SPFx can provide a "upgrade the previous project" feature. It's not easy journey for developers to upgrade their previous SPFx project, especially when new version includes some config or break-compiling changes. At least, a upgrade report or instruction generated from the latest SPFx would be helpful.

[patmill]

OK. I'm going to close this now, with one thing for us to do, and one thing for you to do.
We'll work on more clearly documenting changes above and beyond the changes to the APIs in a given release, and document changes to config files as well.
As far as a new tool to upgrade existing projects, I'm going to ask you to open a request in https://sharepoint.uservoice.com in the developer section. We're trying to not have a bunch of open issues that are feature requests. Thanks.

[shaipetel]

posted:
https://sharepoint.uservoice.com/forums/329220-sharepoint-dev-platform/suggestions/33706876-updating-existing-projects-to-newer-spfx-builds

please vote

[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