BatchExplorer/packages
David Watrous e6d7828f5a Move TypeSpec/Autorest dependencies to root of the repo
This works around an issue using the service package inside the Azure portal
when `bux link` is active. See AB#27200905 for details.
2024-04-05 15:31:55 -04:00
..
bonito-core
bonito-ui
playground
react
service
readme.md

readme.md

Azure Batch Shared User Interface Libraries

This directory contains Typescript libraries intended for use across various Batch UIs. These packages depend on each other and can be built together using the scripts inside the root package.json.

Package Layout

These libraries consist of various NPM packages which are meant to be distributed (in the packages/ directory), along with private utility packages which are for development only (in the util/ directory).

  • bonito-core - A common package intended to be able to run in a Node.js environment as well as a web browser environment. Has minimal external dependencies, and provides various core functions and interfaces such as:

    • A common HTTP layer which wraps specific implementations of HTTP auth and transport (such as the Azure Portal's batch() API for sending/receiving multiple logical HTTP requests in a single request/response)
    • A reactive data layer for forms, intended to act as a view model for a form UI
  • bonito-ui - A React-based component package specifically designed to be deployed in an Azure Portal ReactView blade. Its peerDependencies are tailored toward a specific version of the Azure Portal SDK, and should be kept up to date with the version of the SDK that we are targeting. This packages builds a small AMD-compatible file which excludes any dependencies which the Azure Portal already provides such as React, FluentUI and Redux.

  • service - A package intended to act as a decoupled data access & business logic layer for the Batch service.

  • react - A package containing Batch-specific UI components.

  • playground - A package containing the code to render a UI component playground for developing components in isolation and testing edge cases.

Development Prerequisites

Before developing against these libraries, make sure you have installed:

Building and Running Tests

To build the shared libraries, run the following from the root directory of the repo:

npm install && npm run dev-setup && npm run build

Unit Tests

Unit tests are automatically run via Jest when invoking any build script. To develop tests live, cd to the package's directory then run the command:

npm run test:watch

This will start Jest in an interactive mode and watch the source code for changes, rebuilding and rerunning tests automatically.

To set breakpoints and debug tests, run npm run test:debug, then open Edge or Chrome and go to edge://inspect or chrome://inspect respectively. This should auto-detect the running Node.js debugger port, and allow you to connect the Chromium dev tools. Note that when the debugger connects, execution will have already been paused. To resume, click the play button in your debugger.

Accessibility Tests

The react package includes support for automated accessibility (a11y) testing with axe. Accessibility tests are automatically run in continuous integration (CI) pipelines, but they're not run by most test scripts in development. The accessibility tests can be run explicitly through one of the following methods:

cd packages/react
npm run test:a11y       # Run all accessibility tests
npm run test:a11y:watch # Run all accessibility tests in watch mode
npm run test:all        # Run all React tests including accessibility tests

Developing in a Local Web Server

To start a development server and watch for changes, cd to the root directory of the repository and run the following command:

npm run start

This will start a webpack dev server at http://127.0.0.1:9000 and watch for any changes to the standalone package. To pick up live changes from other packages, run npm run watch either from the same directory as this README.md, or from the individual package directory.