Empacotamento de solução do SharePoint

A tarefa do gulp package-solution analisa /config/package-solution.json para obter diversos detalhes de configuração, inclusive alguns filepaths genéricos, bem como para definir o relacionamento entre os componentes (WebParts e Applications) em um pacote.

O esquema para o arquivo de configuração é o seguinte:

interface IPackageSolutionTaskConfig {
  paths?: {
    packageDir?: string;
    debugDir?: string;
    zippedPackage?: string;
    featureXmlDir?: string;
    manifestsMatch?: string;
    manifestDir?: string;
    sharepointAssetDir?: string;
  };
  solution?: ISolution;
}

Cada arquivo de configuração de pacote tem algumas configurações opcionais para substituir os locais em que a tarefa procura vários arquivos e manifestos de origem e definir o local para gravar o pacote. Além disso, ele tem uma definição de solução necessária, que instrui o gerenciador sobre as relações de vários componentes.

Definição de solução (ISolution)

interface ISolution {
  name: string;
  id: string;
  title?: string;
  supportedLocales?: string[];
  version?: string;
  features?: IFeature[];
  iconPath?: string;
  skipFeatureDeployment?: boolean;
}

Cada arquivo de solução deve ter um name que identifica o pacote na IU do SharePoint. Além disso, cada pacote deve conter um identificador global exclusivo (id), que é usado internamente pelo SharePoint. Opcionalmente, você também pode especificar um número de version no formato "X.X.X.X", que é usado para identificar várias versões do pacote durante a atualização.

Observação

O sistema de controle de versão se aplica somente às definições de Recursos do SharePoint e de Estrutura de Recursos incluídas no pacote. O código e os ativos da nova versão do pacote ficam disponíveis assim que a nova versão do pacote for adicionada ao catálogo de aplicativos, sem precisar atualizar o aplicativo nos sites.

Opcionalmente, a definição da solução também contém uma lista de definições de recursos do SharePoint.

Observação

Se isso for omitido ou estiver vazio, a tarefa criará um único Recurso para cada componente (um mapeamento 1:1).

Definição de recurso (IFeature)

interface IFeature {
  title: string;
  description: string;
  id: string;
  version?: string;
  componentIds?: string[];
  components: IComponent[];
  assets: ISharepointAssets<string>;
}

É importante observar que esta é uma definição para a criação de um recurso do SharePoint e que algumas dessas opções estão expostas na IU. Da mesma forma que a solução, cada recurso possui um número obrigatório title, description, id e version (no formato X.X.X.X). O recurso id também deve ser um identificador global exclusivo.

Cada recurso também pode conter qualquer número de componentes que são ativados quando o recurso é ativado. Isso é definido por meio de uma lista de componentIds, que são identificadores globais exclusivos que devem corresponder à ID no arquivo de manifesto do componente. Se esta lista estiver indefinida ou vazia, o empacotador incluirá cada componente no recurso.

Caminhos de arquivo

interface IPackageSolutionTaskConfig {
  paths?: {
    packageDir?: string;
    debugDir?: string;
    zippedPackage?: string;
    featureXmlDir?: string;
    manifestsMatch?: string;
    manifestDir?: string;
    sharepointAssetDir?: string;
  };
  solution?: ISolution;
}

  • packageDir: Pasta raiz da embalagem. Padrão para ./sharepoint. Todos os outros caminhos são relativos a essa pasta.

  • debugDir: Pasta para gravar o pacote bruto no disco para depuração. Padrão para solution/debug.

  • zippedPackage: Nome do arquivo sppkg a ser criado (incluindo a extensão). O padrão é ClientSolution.sppkg

  • featureXmlDir: pasta contendo o XML de recurso personalizado para importar no pacote. O padrão é feature_xml

    Importante

    Todos os arquivos nessa pasta são incluídos no SPPKG; no entanto, você deve criar um arquivo .rels para seu recurso personalizado para que ele seja incluído no manifesto do pacote.

  • manifestsMatch: glob de correspondência para localizar arquivos de manifesto. Examina dist/ durante a execução no modo normal, mas em deploy/ para produção.

  • manifestDir: caminho para a pasta onde os manifestos são armazenados. O padrão é buildConfig.distFolder

  • sharepointAssetDir: diretório contendo ativos do SharePoint (como elementos de recurso, manifestos de elemento e ações de atualização), que são automaticamente incluídos no pacote do SharePoint. O padrão é assets

Exemplos

Configuração padrão

{
  "solution": {
    "name": "spfx-hello-world-client-side-solution",
    "id": "77fd2eed-55b0-42bf-8b4d-f66730cb0c34",
    "version": "1.0.0.0"
  },
  "paths": {
    "zippedPackage": "solution/spfx-hello-world.sppkg"
  }
}

XM L de recurso personalizado

Para dar suporte ao provisionamento de vários recursos do SharePoint (por exemplo, Modelos de Lista, Páginas ou Tipos de Conteúdo), o XML de recurso personalizado também pode ser injetado no pacote. Isso é usado para provisionar recursos necessários aos aplicativos, mas também pode ser usado para web parts. A documentação de XML do Recurso está localizada em Arquivos Feature.xml.

A tarefa de empacotamento procura o recurso personalizado XML no ./sharepoint/feature_xml. Todos os arquivos dessa pasta são incluídos no pacote de aplicativo final. No entanto, a tarefa depende do conteúdo da pasta _rels/ para determinar quais recursos personalizados são definidos.

Basicamente, ela pressupõe que cada arquivo .xml.rels esteja relacionado a um feature.xml com o mesmo nome no nível superior de feature_xml/ e adiciona uma relação com o arquivo AppManifest.xml.rels que inclui esse recurso no pacote.

Confira também

  • Last updated on