IClientSideComponentManifest interface

All client-side components built on the SharePoint framework need a valid component manifest. This interface represents properties that are required by all types of client-side components like Applications and Web Parts. Component specific manifests will extend this interface to add properties required by that component type.

Extends

Remarks

The schema of this manifest is owned and versioned by Microsoft. Following rules should be followed while changing this schema. This set of rules can also be called the "manifest upgrade rules".

  • For minor changes, new properties can be added to this schema in a backwards-compatible way. i.e. the code that processes the manifest should be able to handle the absence of those new properties.

  • Try to model your changes as minor SemVer increments. Major version changes should be avoided because they impose a migration cost on developers.

  • The 'manifestVersion' should be bumped for all small or big changes.

Properties

alias

A short name usually given by developer. It does not need to be localized and is expected to stay the same through the lifetime of the component. If an application overrides the ClientSideApplication.alias property, ClientSideApplication.alias is given precedence over the value provided in the manifest.

componentType

Type of client-side component. Components with the "Application" type are defined by the "IClientSideApplicationManifest" interface. Components with the "WebPart" type are defined by the "IClientSideWebPartManifest" interface. Components with the "Library" type are defined by the "IClientSideLibraryManifest" interface. Components with the "AdaptiveCardExtension" type are defined by the "IAdaptiveCardExtensionManifest" interface.

loaderConfig

This portion of the configuration describes how the component is to be loaded and initialized by a client. It contains an enumeration of scripts that the component requires along with a single entry point script.

loadLegacyFabricCss

This property is used to keep older components that don't explicitly use fabric CSS. For the most part, webparts build after using spfx 1.1 don't need this.

requiresCustomScript

If true, the component can only be installed on sites where Custom Script is enabled. This should be set to true if the component allows authors to execute arbitrary scripts on the page.

safeWithCustomScriptDisabled

This property is provided for backwards compatibility. It no longer has any effect.

version

Client-side component version. The value of this field is expected to be controlled by the developer of the client-side component.

Property Details

alias

A short name usually given by developer. It does not need to be localized and is expected to stay the same through the lifetime of the component. If an application overrides the ClientSideApplication.alias property, ClientSideApplication.alias is given precedence over the value provided in the manifest.

alias: string;

Property Value

string

Remarks

Usage: A short name to identify a client-side component by developer.

Supported values: Allowed characters are a-z, A-Z, and '-'. Not longer than 40 characters.

Example: "NewFeed"

componentType

Type of client-side component. Components with the "Application" type are defined by the "IClientSideApplicationManifest" interface. Components with the "WebPart" type are defined by the "IClientSideWebPartManifest" interface. Components with the "Library" type are defined by the "IClientSideLibraryManifest" interface. Components with the "AdaptiveCardExtension" type are defined by the "IAdaptiveCardExtensionManifest" interface.

componentType: ComponentType;

Property Value

Remarks

Usage: To help bundling, loading, enumeration, and initialization of components based on their contents.

Supported values: "Application", "WebPart", "Library", "Extension", "AdaptiveCardExtension"

loaderConfig

Note

This API is provided as a preview for developers and may change based on feedback that we receive. Do not use this API in a production environment.

This portion of the configuration describes how the component is to be loaded and initialized by a client. It contains an enumeration of scripts that the component requires along with a single entry point script.

loaderConfig: IClientSideComponentLoaderConfiguration;

Property Value

Remarks

Usage: Loading a component.

See IClientSideComponentLoaderConfiguration for more information and examples.

loadLegacyFabricCss

This property is used to keep older components that don't explicitly use fabric CSS. For the most part, webparts build after using spfx 1.1 don't need this.

loadLegacyFabricCss?: boolean;

Property Value

boolean

requiresCustomScript

If true, the component can only be installed on sites where Custom Script is enabled. This should be set to true if the component allows authors to execute arbitrary scripts on the page.

requiresCustomScript?: boolean;

Property Value

boolean

Remarks

Defaults to false. See https://support.office.com/en-us/article/Turn-scripting-capabilities-on-or-off-1f2c515f-5d7e-448a-9fd7-835da935584f for more information.

Usage: Requires Custom Script to be allowed in order for this component to be installed and run.

safeWithCustomScriptDisabled

Warning

This API is now deprecated.

Use requiresCustomScript instead of safeWithCustomScriptDisabled.

This property is provided for backwards compatibility. It no longer has any effect.

safeWithCustomScriptDisabled?: boolean;

Property Value

boolean

version

Client-side component version. The value of this field is expected to be controlled by the developer of the client-side component.

version: string;

Property Value

string

Remarks

The purpose of this field is to help client-side component developers upgrade their client-side components in a managed way. This helps the consumers of the client-side component make decisions about when and how to upgrade the client-side component. As the developer evolves the code for their client-side component, they can decide to bump the MAJOR, MINOR or PATCH version of the component.

All incompatible API changes should result in a MAJOR version bump. Backwards compatible functionality changes should result in a MINOR version bump, and backwards compatible bug fixes should result in a PATCH version bump. Please see http://semver.org for more details on how to manage the version of your components.

Usage: Versioning and evolving a client-side component safely in a controlled way.

Supported values: string representing a semantic version i.e. MAJOR.MINOR.PATCH

Example: "1.0.0"