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 |
| component |
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. |
| loader |
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. |
| load |
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. |
| requires |
If true, the component behaves as following on sites where custom scripts are not allowed to run: - when the component is a web part, it is not available in the web part picker - every instance of the component that was added to the page while custom scripts were allowed to run, will no longer surface in those pages. Author are still able to remove those components while editing the page |
| safe |
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 behaves as following on sites where custom scripts are not allowed to run: - when the component is a web part, it is not available in the web part picker - every instance of the component that was added to the page while custom scripts were allowed to run, will no longer surface in those pages. Author are still able to remove those components while editing 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"