# SPFX GA!

Welcome to the General Availability of SPFX 1.0.  It's been an exciting and interesting trip so far, and will continue to be.  This is only the first release - expect a steady stream of improvements and features.

# Should you get the new bits yet?
You can get the updated npm packages and use them in the local workbench, and everything should be fine.  However, the rollout of the code to the servers will be done in stages over the course of several days.  By sometime next week 100% of the farms should have it.  We do this to monitor the rollout and make sure we don't have any issues.

# Will I get to use SPFX and client side webparts now?
There are really two different things at play.  One is the code being available on all the farms, the second is the feature being enabled for a given tenant.  Similar to how the code rolls out across the farms, the feature will be rolled out to tenants.  We will start with the same first-release tenants (not users, tenants) that have SPFX today.  Over the course of a couple of weeks, it should roll to all tenants.  You will know if it has reached a given tenant because uploading the package into the app catalog will say it is valid.  Note that even tenants that don't have the ability to upload packages can still try out SPFX, they will just be limited to the local and hosted workbench (found at _layouts/15/workbench.aspx).

# Getting the new bits
If you already have the yeoman generator installed, uninstall it (`npm uninstall -g @microsoft/generator-sharepoint`)
Install the latest version (1.0.0) (`npm install -g @microsoft/generator-sharepoint@latest`)

# Updating your existing projects
As usual, it's probably cleanest to start fresh, but if you want to migrate an RC0 project, follow these steps.
## Update your package.json file
### Open package.json and set the versions of the following packages in the "dependencies" section. 

+    "@microsoft/sp-client-base": "~1.0.0"

+    "@microsoft/sp-core-library": "~1.0.0"

+    "@microsoft/sp-webpart-base": "~1.0.0"

### Update your "devDependencies" section.  Note the two new @types package references

+    "@microsoft/sp-build-web": "~1.0.0"

+    "@microsoft/sp-module-interfaces": "~1.0.0"

+   "@microsoft/sp-webpart-workbench": "~1.0.0"
 

# Changes from RC0
+  There are only a few changes in the actual framework code.  The bulk of our work between RC0 and GA had to do with stability and future-proofing.  It is our explicit goal that the parts you create today should continue to work for years to come.  But fixes made to the underlying service continue to be supplied without issues, we don't have 7 different minor and patch versions of framework code loaded, etc.  There is still some work to do in this area for some components - we'll get to those.
+  The biggest change to the code itself is that we incorporated the strict null checks flag into SPFX, meaning that you can also enable this flag in your projects.  It changed the API slightly, but should only be noticed if you enable strict null checks yourself.
+  The other noticable changes are in the default code that is generated by running yo.  1.0.0 is the version of the packages (woot!).  We now reference @types with a strict version (no more lodash errors).
+  We have feature XML support (along with upgrade).  This can be used to provision needed fields, content types and lists for the web part in “elevated” mode.  We'll write up some posts on this in more detail.
+  We have finalized the serialization format on classic pages.  You should delete and re-add your webparts.  We'll support the old serialization format for a short while, then it will cease to work.
+ require('./config/docs.config.html'); now returns object in GA rather than string like RC0 ( thanks weshackett )

# Known gaps
We have temporarily removed office-ui-fabric-react from the react template until we can get the package moved to a future-proof form.  We expect that to take a couple of weeks.

# What's coming up?
+  Projects built with the other packages will continue to work for a short while (a couple of weeks or so), then they will generate errors saying that version 0.x.y couldn't be loaded.
+  We will allow a webpart developer to specify what version of fabric they are using, and set that version on the webpart div.  This will protect a webpart from being broken when fabric makes a major change, and let all webparts that use a specific major version of fabric to share the fabric code.
+  We will allow individual pieces of office-ui-fabric-react to be incorporated statically into your webparts.  This will ensure that the packages remain small, but are protected from changes.