Release Strategy

Reshaped follows semantic versioning using the major.minor.patch format.

• Major releases include new features that introduce breaking changes. This can affect component props, naming, or include significant visual updates. Upgrading to a major version may require changes in your codebase, but we provide a migration guide with each release. We release major versions once a year, usually right after Figma Config, so we can adopt the latest design updates.

• Minor releases add new features without breaking changes. These updates may include visual improvements but don't require code changes. Minor releases are announced in the changelog and typically happen once a month.

• Patch releases are focused on fixing bugs. They don't require any changes in your product code. Patch versions are released as soon as the fix is merged into the main branch.

• Canary releases are pre-release versions of upcoming minor updates. They allow you to test new features before they're officially released. Canary versions are published from the canary branch and don't block patch releases.

To focus on developing new features and ensuring high quality, we provide limited support for outdated major releases while offering guidelines for smoother migration to the latest versions.

• Latest major release: Active development and complete support.
• Previous major release: Critical bug fixes only.

Reshaped is compatible with the latest stable releases of all major browsers. No additional polyfill setup is required.

Supported Versions

• Chrome/Edge: 99+
• Safari: 15.4+
• Firefox: 97+

Internet Explorer 11 is not supported as it's been officially deprecated.

This list may be updated over time, with changes announced on our changelog page as part of the release notes. We use caniuse.com to track browser adoption and feature distribution for decision-making.

Features that we're evaluating for the future use but can't yet adopt because of their browser support.

Can be used in components to apply responsive styles based on the parent container. For example, when photo carousel is rendered in a Modal, we don't care about what's the size of the screen to define the items size. Might replace current responsive properties if they will use container queries instead of regular media queries and use body as the default container.

Can help revamp the typography to achieve accurate alignment of the text content with other components. Would be a breaking change and can only be applied in a major release when generally available.

Being able to natively change the value of the media-queries viewport sizes would let us drop PostCSS as a dependency since this is the only plugin that we truly need for writing responsive CSS on the product side. It's not planned to be implemented in the near future and there is a potential container queries workaround to look into.

Potentially replace the custom Flyout positioning with native positioning.

Style components conditionally based on the variables defined by their parents. Could be used for defining styles for component variants based on inline variables instead of classes and for changing components behavior when inserted in other components.

Potentially remove generated on color tokens and auto generate accessible colors instead.

System color mode can currently be resolved only on the client through media queries in css and matchMedia in JS. That means that system color mode fully works on client-side.

For SSR – there are multiple challenges:

• CSS variables. If themes are assigned based on selectors (data-rs-theme, data-rs-color-mode), we can inline a short synchronous script in the head tag that will update the root theme attribute. That solves most of the cases but leaves the problem of scoped themes and scoped dark mode on the table, where we need to figure out how to handle their inheritance. It adds additional complexity, but can be solved if system color mode is passed to the root provider with a system value explicitly.
• Dark mode toggle. Can be solved by adding a “system” option to the toggle for cases that want to support system level theming, but won't work for dark / light switches that want to only support system theme as default
• JSX content. Since JSX is rendered on the client after the hydration, we can't change JSX content based on the theme (e.g. 3rd party banners / images) without the content flash.

Properties:

• Native slots support. Avoid creating custom slot utilities and support auto-layout composition inside the slots natively.
• Restricted properties in nested instances. Sometimes these properties are defined by the parent variants and are not meant to be customized.
• Repeated items to insert the same component as a child of another component and control their amount, e.g. items in menus.
• Full control over properties order. Right now variants have to be displayed first.

Styles/Variables:

• Option to display the variable name instead of its value for units, e.g. x1 instead of 4.
• Calculated variable values, e.g. x2 is x1 * 2 or applying lightness / opacity modifiers to existing color variables.
• Attaching variable values to component properties to reduce the amount of variants, e.g. rounded property only needs to change the radius of a single element. Can also be achieved by making boolean properties more sophisticated.
• Negative margin in auto-layout and being able to make a unit negative without creating a new variable.
• Opacity modifiers for the color variables without having to create a new variable

General

• Preview specific component variants directly in the component search
• Native keywords support when searching components instead of relying on their description