---
title: Extend the front-end with blueprints in Spire
slug: configured-commerce/docs/extending-the-front-end-with-bluesprints-in-spire
docTags: 
createdAt: 2026-08-13T10:46:22.000Z
---

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](docId:_alevzIx5AAyVecgmIscS) 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.