Skip to main content

PR Checklist

This document outlines the requirements for submitting a pull request (PR) to the project.

General guidelines​

  • Ensure the build passes.
  • No ESLint errors.
  • Achieve 100% code coverage.
  • The submission should match the specification.
  • Maintain a single commit, or squash multiple commits.
  • Use single quotes ' ' for strings.
  • If submitting a sample, ensure it is properly formatted and indented.

Coding standards​

  • Command options should follow the naming convention (kebab-case for CLI flags).
  • The command should have a correct name.
  • The command name added to commands.ts should be placed so that commands are sorted alphabetically.
  • The command class is named following the pattern [Service][Command]Command. For example, SpoWebRemoveCommand.
  • Verify the command works as expected.
  • List commands must have readable output in text mode, with each item fitting in one row of 130 characters preferably.
  • Avoid commented-out code and usage of any types, preferring specific types.
  • Remove commands should include a force option.
  • For bug fixes, include a test for the fixed use case.
  • Avoid unnecessary retrieval of form digest.
  • Handle failed promises properly when responseType: 'json' is used by using handleRejectedODataJsonPromise.
  • Escape user input in XML and URLs using formatting.encodeQueryParameter() or formatting.escapeXml().
  • Verbose and debug outputs are logged to stdErr (logger.logToStderr instead of logger.log).
  • Do not do conditional output in JSON output mode; use defaultProperties for defining default properties in list commands.
  • For commands with multiple options where the user is required to choose one, define these options using a custom Zod validation.
  • Use async/await instead of promise/then.
  • npm test must pass without errors.

Documentation​

  • Include an mdx help page.
  • Reference the mdx help page in the sidebar navigation.
  • Start all code samples with m365.
  • Ensure samples use long names of options rather than short ones.
  • If there is an option modifying the output, include responses for both default and modified output.
  • For a command page, ensure it includes the following sections: title, description, usage, options, examples, permissions, and response. In some cases a remarks section is also allowed.