Volto Hands-On is a training on how to create your own website.

Below is a list of commands you will probably find useful.

Installs and checkouts the mrs-developer directives (make develop), creates a shortcut to the Volto source code (omelette folder), then triggers the install of the frontend environment.

Runs the project in development mode. You can view your application at http://localhost:3000

The page will reload if you make edits.

Builds the app for production to the build folder.

The build is minified and the filenames include the hashes. Your app is ready to be deployed!

Runs the compiled app in production.

You can again view your application at http://localhost:3000

Runs the test watcher (Jest) in an interactive mode. By default, runs tests related to files changed since the last commit.

Runs the test i18n runner which extracts all the translation strings and generates the needed files.

mrs-developer is a great tool for developing multiple packages at the same time.

mrs-developer should work with this project by running the configured shortcut script:

make develop

Volto's latest razzle config will pay attention to your tsconfig.json (or jsconfig.json) file for any customizations.

In case you don't want (or can't) install mrs-developer globally, you can install it in this project by running:

yarn add -W mrs-developer

In order to run localy (while developing) the project acceptance tests (Cypress), there are some Makefile commands in place (in the repo root). Run them in order:

start-test-acceptance-server: Start server fixture in docker (previous build required)

start-test-acceptance-frontend: Start the Core Acceptance Frontend Fixture in dev mode

test-acceptance: Start Core Cypress Acceptance Tests in dev mode

full-test-acceptance: Start the whole suite (backend + frontend + headless tests) Cypress Acceptance Tests in headless (CI) mode

This repository uses the Betterleaks GitHub Action to scan the current repository content on every push and pull request. The scan uses the rules in .gitleaks.toml and uploads a betterleaks-report artifact when a finding is detected.

If the optional SMTP secrets are configured, failed scans also send an email to the last commit committer. The workflow expects these repository or organization secrets:

• SMTP_URL
• SMTP_PORT (optional, defaults to 25)
• SMTP_EMAIL
• SMTP_PASSWORD (optional if the SMTP server does not require authentication)

Port 465 is sent with direct TLS; other ports use the default SMTP handshake. The email includes a short finding summary from the redacted Betterleaks report, including the redacted matched line from each finding.

There are three common outcomes:

1. Everything is OK. The Betterleaks / Scan for secrets check is green and no action is needed. Regular references to runtime values are OK, for example:

   const tokenFromCookie = req.universalCookies.get('auth_token');

2. A real secret was found. The check is red and the workflow log asks you to download the betterleaks-report artifact. Open the artifact from the GitHub Actions run and check the reported file, line and rule. Remove the committed value, move it to the proper secret store, and rotate it if it was exposed. A report entry looks like this:

   {
     "RuleID": "secret-literal-assignment",
     "File": "src/config.js",
     "StartLine": 12,
     "Secret": "[REDACTED]"
   }

3. The finding is a false positive. Keep the value only if it is clearly not sensitive, such as a test fixture, placeholder, or public example. Add betterleaks:allow on the same line and include a short explanation in the pull request.

   const testPassword = 'admin'; //betterleaks:allow

   password: "admin" #betterleaks:allow

Do not add betterleaks:allow to real credentials.