Extend the front-end with blueprints in Spire

The goals of Spire are to ensure front-end upgradability while maintaining backward compatibility on the public surface area of Spire for site extensions.

Locally, you work with the full Spire source code. When you build and deploy your Blueprint, Optimizely ignores any changes you make to the core Spire code, which you should only change to assist with troubleshooting issues. This includes everything exported directly or indirectly, except for \modules\shell and UNSAFE_ code.

Keep these guidelines in mind when extending Spire:

• Optimizely uses a plug-in called goodfences to enforce the restriction not to reference the shell code.
• Some areas of code are currently prefixed with UNSAFE_, which Optimizely will change in the future, that you should not import directly.
  There are functions to get at the UNSAFE_ data safely for areas Optimizely plans on maintaining compatibility, such as the Redux state. The Redux state includes state.UNSAFE_currentPage.page, which you can use to get the current page object. Referencing it this way in mapStateToProps causes issues, so Optimizely added a function getCurrentPage to \client-framework\Store\Data\Pages\PageSelectors.ts, which is the backward compatible way of getting the current page object.
• Optimizely does not currently support modifying package.json to import
  additional third-party libraries. See Install third-party NPM packages for information.
• If a blueprint has a widget or page replacing a base code widget or page, you must include it in the overrides folder; an error will occur if it is left out.