Technical Reference & Contributing Guidelines
πββοΈ Contribution guidance
Section titled βπββοΈ Contribution guidanceβπ Before you start working on an issue, be sure to check out our Contribution guidelinesπ.
π Repository branches
Section titled βπ Repository branchesβYou may have already noticed that this repo maintains two branches: main
and dev
. Whatβs even more important is that every feature branch should be created based on dev
branch and Pull Requests should target dev
branch not main
. Itβs important to understand why the meaning and purpose of each branch:
main
- based on this branch new major and minor releases are created. Only critical bug fixes or feature updates go directly to this branch. All others should first be merged todev
branch and then merged to fromdev
tomain
with a separate PR. This branch is main repository branch and keeping clean changes history is important.dev
- based on this branch pre-releases are created. Every change should be merged to this branch first with a PR before they get merged tomain
branch. During the release flow, this branch may be rebased and force pushed againstmain
branch, so it may be recreated based on the currentmain
branch state.
π Solution details
Section titled βπ Solution detailsβThe project is a VS Code extension that uses many typical VS Code extension components like panels, providers, commands, webviews etc.
π Project structure
Section titled βπ Project structureβThe main definition of the project is (as always) in the package.json
file. Besides the dependencies in that file, we may find most of the VS Code extension capabilities (some almost fully defined like welcome experience or walkthrough or commands) and details present in the VS Code marketplace.
βββ assets // Keeps all the graphical files connected to the project (either used in the extension or in docs)β βββ images // Keeps images used in readme fileβββ data // Keeps .json files which store info about all the samples or scenarios of a given PnP sample gallery repoβββ scripts // Keeps all the scripts used for maintenance or in pipelinesβββ srcβ βββ chat // GitHub Copilot participant related filesβ βββ constants // Types, dictionary data, or static stringsβ βββ models // Models/interfaces used as method inputs or outputsβ βββ panels // Panels are the sections you see in the action pane. Here we decide if we show welcome experience or the SPFx project panels and what is their behaviorβ βββ providersβ βββ services // Groups functionalities dedicated to a specific feature or service (like Scaffolder)| βββ testsβ βββ utils // Groups all small helper methodsβ βββ webview // Groups all webviews used in this extensionβ βββ extension.ts // Main point of the extension that runs on start and registers all other componentsβββ syntaxesβββ webpackβββ .eslintrc.jsonβββ .vscodeignoreβββ postcss.config.jsβββ tailwind.config.jsβββ tsconfig.json
π Tech used
Section titled βπ Tech usedβThe extension was developed using the following tech:
- CLI for Microsoft 365
- React.js
- TypeScript
- Tailwindcss
- Webpack
π Extension Capabilities
Section titled βπ Extension CapabilitiesβThe extension uses the following VS Code extension capabilities:
- chat extension
- commands
- walkthroughs
- notifications
- webviews
- extending activity bar
- panel/views in activity bar
π¦Ύ Pipelines
Section titled βπ¦Ύ PipelinesβCurrently in the project we have 4 pipelines:
- Pre-Release - This pipeline should be used only for
dev
branch. It is only possible to trigger this pipeline manually. The aim is to release a VSCode extension version as a Pre Release so specifying--pre-release
option. It should be used to deliver the latest features that were developed and will be released with a new major or minor version, so that it may be tested in a pre-release (beta) in order to collect feedback. Before this pipeline is started we should check if:- in the package.json file the version was increased in the patch section. So for example x.y.1
- Main Release - This pipeline should be used only for
main
branch. It is possible to trigger it manually but also it will be started when a newrelease
is issued via GitHub (so a new tag is created as well). It should be used to deliver a new major or minor version of the extension. Before this pipeline is started we should check if:- in the package.json file the version was increased in either major or minor parts. So for example 1.1.x
- the changelog file was updated with details for the new release
- all the new features are documented in the wiki and added to the readme file
- a vsce package is created so that it may be included in the release
- Update samples data - It actually does not matter on which branch this pipeline will run as it does not work with the source files of this project. It may be triggered manually or it will trigger as scheduled, once a week on Saturday. The aim of this pipeline is to recheck the PnP SPFx web parts, SPFx extensions, ACEβs sample repos and create local
json
files kept in the data folder which will have the info about each sample. The pipeline creates a PR so that the changes may be reviewed and merged manually (they have to be merged to themain
branch). The SharePoint Framework Toolkit uses those files in order to create the sample gallery views. That way allows us to keep the samples up to date without the need to release a new version of the extension. There are no prerequisites that need to be met in order to run this pipeline. - Create .vsix package - The aim of this workflow is to create .vsix package to be downloaded from the artifacts and tested locally.
π§ͺ Tests
Section titled βπ§ͺ TestsβTo run tests in debug:
- install extension https://marketplace.visualstudio.com/items?itemName=ms-vscode.extension-test-runner
- run
npm run package && npm run compile-tests
- run
Extension Tests
in debug
To run:
- run
npm run package && npm run compile-tests
- run
npm run test
and check the result in terminal