Documentation & NPM updates

.github/workflows/release-tooling.yml

@@ -0,0 +1,41 @@
+name: Release Tooling
+on:
+  push:
+    branches:
+      - main
+
+env:
+  NODE_VERSION: 22.13.0
+
+permissions:
+  contents: write
+  issues: write
+  pull-requests: write
+  pages: write
+  id-token: write
+
+jobs:
+  release-please:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: googleapis/release-please-action@v4
+        with:
+          token: ${{ secrets.RELEASE_PLEASE_TOKEN }}
+          release-type: node
+
+# This could likely be shifted to publish-package if we only want to update SB with release versions
+  deploy-storybook:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v6
+        with:
+          fetch-depth: 0
+      - uses: actions/setup-node@v6
+        with:
+          node-version: ${{ env.NODE_VERSION }}
+      - uses: bitovi/github-actions-storybook-to-github-pages@v1.0.3
+        with:
+          install_command: npm ci
+          build_command: npm run build-storybook
+          path: storybook-static
+          checkout: false

.gitignore

@@ -1,15 +1,3 @@
-# This file specifies intentionally untracked files that all Moodle git
-# repositories should ignore. It is recommended not to modify this file in your
-# local clone. Instead, use .git/info/exclude and add new records there as
-# needed.
-#
-# Example: if you deploy a contributed plugin mod/foobar into your site, put
-# the following line into .git/info/exclude file in your Moodle clone:
-# /mod/foobar/
-#
-# See gitignore(5) man page for more details
-#
-
 # Swap files (vim)
 [._]*.s[a-v][a-z]
 [._]*.sw[a-p]
@@ -18,35 +6,7 @@
 [._]sw[a-p]
 # Temporary files including undo
 *~
-#
-/cscope.*
-/.patches/
-.phpstorm.*
-!/.phpstorm.meta.php/
-/.phpstorm.meta.php/*
-!/.phpstorm.meta.php/di.php
-/nbproject/
-CVS
 .DS_Store
-/.settings/
-/.project
-/.buildpath
-/.cache
-.phpunit.result.cache
-phpunit.xml
-# Composer support. Do not ignore composer.json, or composer.lock. These should be shipped by us.
-composer.phar
-/vendor/
-atlassian-ide-plugin.xml
-/node_modules/
-.eslintignore
-.stylelintignore
-/jsdoc
-.hugo_build.lock
-phpcs.xml
-jsconfig.json
-UPGRADING-CURRENT.md
-.phpunit.cache
 
 # JetBrains
 .idea/*
@@ -55,12 +15,19 @@ UPGRADING-CURRENT.md
 .idea/jsLinters/*
 !.idea/jsLinters/eslint.xml
 
+# PHPStorm
+.phpstorm.*
+!/.phpstorm.meta.php/
+/.phpstorm.meta.php/*
+!/.phpstorm.meta.php/di.php
+
 # VSCode
 .vscode/*
 !.vscode/extensions.json
 !.vscode/settings.json
 
 /dist/
+/node_modules/
 /storybook-static/
 build-storybook.log
 /coverage/

CONTRIBUTING.md

@@ -1,11 +1,96 @@
-# Contributing to the Moodle Developer Resources
+# Contributing to the Moodle Design System
 
-The Moodle Design System is a MoodleHQ driven project however, we welcome suggestions from anyone who wants to help improve it.
+Thank you for your interest in contributing to the Moodle Design System! This project is driven by MoodleHQ, but we welcome suggestions and contributions from everyone.
 
-If you plan to contribute, then you may wish to setup a local development
-environment to make it easier to do so.
+## Table of Contents
+- [Getting Started](#getting-started)
+- [Prerequisites](#prerequisites)
+- [Development Setup](#development-setup)
+- [How to Contribute](#how-to-contribute)
+- [Code Style, Linting & Commit Messages](#code-style-linting--commit-messages)
+- [Submitting Changes](#submitting-changes)
+- [Documentation Contributions](#documentation-contributions)
+- [Review Process](#review-process)
+- [Release Process](#release-process)
+- [Code of Conduct](#code-of-conduct)
+- [Getting Help](#getting-help)
 
-We highly recommend that you read our [TODO: design system contributions guide](#), which includes important information on [TODO: getting started](#getting-started).
+## Getting Started
 
-For full details and information on how you can contribute to the Moodle Developer Resource project, we recommend taking a look at
-our [Contributors guide](https://moodledev.io/general/documentation/contributing).
+Please read our [Contributors Guide](https://moodledev.io/general/documentation/contributing) for an overview of the contribution process and best practices.
+
+## Prerequisites
+
+- **Node.js** v22.13.0 or higher
+- **npm**
+- **Git**
+
+## Development Setup
+
+To set up a local development environment:
+
+1. **Clone the repository:**
+   ```sh
+   git clone https://github.com/moodlehq/design-system.git
+   cd design-system
+   ```
+2. **Install dependencies:**
+   ```sh
+   npm install
+   npx playwright install
+   ```
+3. **Run Storybook (development server):**
+   ```sh
+   npm run storybook
+   ```
+
+## How to Contribute
+
+- **Report bugs or request features:** Please post them to [Moodle Design System Jira (MDS)](https://moodle.atlassian.net/browse/MDS).
+- **Work on an issue:** Comment on the issue to let others know you are working on it.
+- **Submit a pull request:**
+  - Fork the repository and create a new branch for your changes (e.g., `feat/your-feature` or `fix/your-bug`).
+  - Follow the code style and commit message guidelines.
+  - Ensure all tests pass before submitting.
+
+## Code Style, Linting & Commit Messages
+
+- Follow the existing code style. Run `npm run lint` to check for linting errors.
+- Commit messages should follow the [Conventional Commits@1.0.0](https://www.conventionalcommits.org/en/v1.0.0/#summary) specification.
+- Husky and lint-staged are used to run linters and tests on staged files before commits and pushes.
+- Add or update tests as appropriate.
+- See the [Coding Standards](README.md#coding-standards) section in the README for more details.
+
+## Submitting Changes
+
+1. Ensure your branch is up to date with `main`.
+2. Run all tests and ensure they pass:
+   - `npm run test-storybook` (Storybook visual tests)
+   - `npm run test-unit` (unit tests)
+   - `npm run test-unit-coverage` (unit test coverage)
+3. Open a pull request with a clear description of your changes.
+4. Participate in the code review process and make any requested changes.
+
+## Documentation Contributions
+
+Improvements to documentation are welcome! Please update relevant markdown files or Storybook docs as needed.
+
+## Review Process
+
+- Pull requests are reviewed by the Moodle HQ Design System team.
+- Reviews may take a few days depending on team availability.
+- Please respond to feedback and make requested changes promptly.
+
+## Release Process
+
+- Releases are automated using [Release Please](https://github.com/googleapis/release-please).
+- See the [CHANGELOG](CHANGELOG.md) for release history and updates.
+
+## Getting Help
+
+For any contributions, issues, or support, please reach out to the Moodle HQ Design System team through the following channels:
+- Submit a ticket on the [MDS project on Moodle Tracker](https://tracker.moodle.org/browse/MDS)
+- Join our [Matrix channel](https://matrix.to/#/!BmKCxoEFOvaJrscitV:moodle.com?via=moodle.com&via=matrix.org&via=lern.link)
+- Join the [Moodle Design System PAG course](https://moodle.org/course/view.php?id=17258)
+
+Thank you for helping improve the Moodle Design System!

README.md

@@ -131,6 +131,7 @@ You can run these tests using the following commands:
 ```bash
 # Install dependencies.
 npm install
+npx playwright install
 # Run unit tests.
 npm run test-unit
 # Run unit tests with coverage report.
@@ -150,13 +151,13 @@ npm run build
 
 The built files will be located in the `dist/` directory.
 
-A [CHANGELOG](CHANGELOG) is automatically generated for each release using [Release Please](https://github.com/googleapis/release-please)
+A [CHANGELOG](CHANGELOG.md) is automatically generated for each release using [Release Please](https://github.com/googleapis/release-please)
 
 GitHub Actions are set up to automatically build the design system on each push to the main branch that has been tagged with a version number.
 
 ## CHANGELOG
 
-See [CHANGELOG](CHANGELOG) for release history and updates.
+See [CHANGELOG](CHANGELOG.md) for release history and updates.
 
 ## Contributing & Support
 

SECURITY.md

@@ -1,15 +1,65 @@
-## Security
+# Security Policy
 
-TODO: Get copy from Mick & Julia.
+We take the security of our project seriously. If you discover a security vulnerability, please follow the instructions below to report it responsibly.
+
+## Scope
+
+This policy applies to vulnerabilities in the Moodle Design System codebase and its dependencies. Issues related to third-party services, social engineering, or denial-of-service attacks are out of scope.
 
 ## Reporting Security Issues
 
-**Please do not report security vulnerabilities through public GitHub issues.**
+**Do not report security vulnerabilities through public GitHub issues.**
+
+Instead, please report security issues by creating an issue at [Moodle Design System tracker](https://moodle.atlassian.net/browse/MDS).
+
+When reporting, please include:
+- A clear description of the vulnerability
+- Steps to reproduce the issue
+- The impact and potential risk
+- Affected versions or components
+- Any relevant logs, screenshots, or proof-of-concept code
+
+We aim to acknowledge your report within 3 business days and provide a resolution within 30 days. We may request additional information to help us resolve the issue.
+
+## Timeline
+
+1. **Triage:** We review and validate the report.
+2. **Investigation:** We assess the impact and determine a fix.
+3. **Resolution:** We implement and test the fix.
+4. **Disclosure:** We coordinate public disclosure with the reporter, if appropriate.
+
+Duplicate or low-severity issues may be closed with an explanation.
+
+## Supported Versions
+
+We provide security updates for the latest major version. Older versions may not receive security fixes.
 
 ## Preferred Languages
 
 We prefer all communications to be in English.
 
-## Policy
+## Disclosure Policy
+
+We follow the principle of [Responsible Disclosure](https://en.wikipedia.org/wiki/Responsible_disclosure). We ask that you give us a reasonable amount of time to address the issue before disclosing it publicly.
+
+## Credit
+
+We appreciate responsible reporters and, with your permission, will credit you in our release notes. If you wish to remain anonymous, please let us know.
+
+## Privacy
+
+All vulnerability reports are handled confidentially. We will not share your information outside the security response team without your consent.
+
+## Legal
+
+We will not pursue legal action against individuals who report vulnerabilities in good faith and follow this policy.
+
+## Security Tools
+
+We use automated tools (e.g., Dependabot) to monitor our dependencies for known vulnerabilities.
+
+## Policy Updates
+
+This policy may be updated from time to time. Please refer to the repository for the latest version.
 
-Moodle follows the principle of [Responsible Disclosure](http://moodledev.io/general/development/process/security).
+Thank you for helping keep our project and community safe.

package.json

@@ -1,5 +1,5 @@
 {
-  "name": "design-system",
+  "name": "@moodlehq/design-system",
   "version": "0.0.1",
   "description": "The Moodle Design System",
   "main": "dist/index.cjs.js",
@@ -91,7 +91,17 @@
     "type": "git",
     "url": "git+https://github.com/moodlehq/design-system.git"
   },
-  "author": "",
+  "keywords": [
+    "moodle",
+    "design-system",
+    "ui-library",
+    "react",
+    "typescript",
+    "storybook",
+    "vite",
+    "components"
+  ],
+  "author": "Moodle HQ",
   "license": "GPL-3.0-only",
   "bugs": {
     "url": "https://github.com/moodlehq/design-system/issues"