Merge branch 'master' of https://github.com/sugarlabs/musicblocks

Author: thevanshit

.github/workflows/node.js.yml

@@ -15,7 +15,7 @@ jobs:
 
         strategy:
             matrix:
-                node-version: [18.x, 20.x]
+                node-version: [20.x, 22.x]
 
         steps:
             - name: Checkout code

…thub/workflows/po-to-json-autocommit.yml …thub/workflows/po-to-json-validation.yml.github/workflows/po-to-json-autocommit.yml renamed to .github/workflows/po-to-json-validation.yml .github/workflows/po-to-json-autocommit.yml renamed to .github/workflows/po-to-json-validation.yml

@@ -1,12 +1,12 @@
-name: Auto-convert PO to JSON and commit
+name: Convert PO to JSON and verify changes
 
 on:
   push:
     paths:
       - 'po/**/*.po'
 
 jobs:
-  convert-and-commit:
+  convert-and-verify:
     runs-on: ubuntu-latest
 
     steps:
@@ -30,7 +30,7 @@ jobs:
           echo "$(cat changed_po_files.txt)" >> $GITHUB_OUTPUT
           echo "EOF" >> $GITHUB_OUTPUT
 
-      - name: Run conversion script
+      - name: Convert PO files to JSON
         if: steps.find_po.outputs.po_files != ''
         run: |
           mkdir -p locales
@@ -39,18 +39,13 @@ jobs:
             python3 convert_po_to_json.py "$po_file" "locales"
           done < changed_po_files.txt
 
-      - name: Commit and push updated JSON
+      - name: Verify JSON conversion changes
         if: steps.find_po.outputs.po_files != ''
         run: |
-          git config --global user.name "github-actions[bot]"
-          git config --global user.email "github-actions[bot]@users.noreply.github.com"
-          
-          git add locales/*.json
-
-          if git diff --cached --quiet; then
-            echo "✅ No JSON changes to commit."
+          if ! git diff --quiet locales/; then
+            echo "❌ Generated translation JSON files have changes that need to be committed."
+            echo "Please run the PO-to-JSON conversion locally and commit the generated files in locales/."
+            exit 1
           else
-            git commit -m "chore(i18n): auto-update JSON files from updated PO files"
-            git push origin ${{ github.ref }}
-            echo "🚀 Pushed updated JSON files."
+            echo "✅ Translation JSON files are verified and up to date."
           fi

.github/workflows/pr-cypress-e2e.yml

@@ -0,0 +1,43 @@
+name: E2E Test
+
+on:
+  pull_request:
+    types:
+      - opened
+      - synchronize
+  push:
+    branches:
+      - master
+
+jobs:
+  e2e:
+    name: Run Cypress E2E Tests
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout Repository
+        uses: actions/checkout@v4
+
+      - name: Setup Node.js
+        uses: actions/setup-node@v4
+        with:
+          node-version: '20'
+          cache: 'npm'
+
+      - name: Run Cypress E2E Tests
+        uses: cypress-io/github-action@v6
+        with:
+          install-command: npm ci
+          start: npm start
+          wait-on: 'http://127.0.0.1:3000'
+          wait-on-timeout: 120
+          browser: chrome
+          config: video=false
+
+      - name: Upload Cypress Screenshots on Failure
+        if: failure()
+        uses: actions/upload-artifact@v4
+        with:
+          name: cypress-screenshots
+          path: cypress/screenshots
+          if-no-files-found: ignore

.github/workflows/security_scan.yml

@@ -18,7 +18,7 @@ jobs:
       - name: Setup Node.js
         uses: actions/setup-node@v4
         with:
-          node-version: '18'
+          node-version: '20'
 
       - name: Install Dependencies
         run: npm install

CONTRIBUTING.md

@@ -1,17 +1,16 @@
 ## <a name="CONTRIBUTING"></a>Contributing
 
 We welcome contributions of all kinds — whether it’s code,
-documentation, music, lesson plans, artwork, or ideas.  Music Blocks
+documentation, music, lesson plans, artwork, or ideas. Music Blocks
 is a community-driven project, and every meaningful contribution helps
 improve the platform for learners and educators around the world.
 
 If you’re new to the project, start by setting up the local
-development environment using the guide linked above, then explore
+development environment using the guide linked below, then explore
 open issues or discussions to find a place to contribute.
 
 - [How to set up a local server](README.md#how-to-set-up-a-local-server)
 
-
 ### Special Notes
 
 Music Blocks is being built from the ground-up, to address several
@@ -50,9 +49,12 @@ following resources:
 - [JavaScript tutorial - w3schools.com](https://www.w3schools.com/js/default.asp)
 - [JavaScript reference - MDN Web Docs](https://developer.mozilla.org/en-US/docs/Web/JavaScript)
 
-Programmers, please follow these general [guidelines for
+For code contributions, please follow these general [guidelines for
 contributions](https://github.com/sugarlabs/sugar-docs/blob/master/src/contributing.md).
 
+### AI guidelines
+
+Follow [AI guidelines for Sugar Labs](https://github.com/sugarlabs/sugar-docs/blob/master/src/contributing.md#ai-guidelines-for-sugar-labs)
 
 ### Before You Push
 
@@ -64,8 +66,20 @@ npx prettier --check .    # Formatting
 npm test                  # Jest
 ```
 
+NOTE: Only run ```prettier``` on the files you have modified.
+
 If formatting fails, run `npx prettier --write .` to fix it.
 
+### After your PR is merged
+
+Please note that production deployments of Music Blocks are **manual**.
+
+This means that even after your pull request is merged, your changes may not immediately appear. Your update will become visible after the next official release is deployed.
+
+If your changes are not visible right away, it does **not** indicate a problem with your PR or implementation.
+
+This note is included to prevent contributors from spending time debugging caching or deployment issues unnecessarily.
+
 ### License Header
 
 Music Blocks is licensed under the [AGPL](https://www.gnu.org/licenses/agpl-3.0.en.html).
@@ -129,60 +143,60 @@ Feel free. But, please don't spam :p.
 ### Keep in Mind
 
 1. Your contributions need not necessarily have to address any
-discovered issue. If you encounter any, feel free to add a fix through
-a PR, or create a new issue ticket.
+   discovered issue. If you encounter any, feel free to add a fix through
+   a PR, or create a new issue ticket.
 
 2. Use [labels](https://github.com/sugarlabs/musicblocks/labels) on
-your issues and PRs.
+   your issues and PRs.
 
 3. Please do not spam with many PRs consisting of little changes.
 
 4. If you are addressing a bulk change, divide your commits across
-multiple PRs, and send them one at a time. The fewer the number of
-files addressed per PR, the better.
+   multiple PRs, and send them one at a time. The fewer the number of
+   files addressed per PR, the better.
 
 5. Communicate effectively. Go straight to the point. You don't need
-to address anyone using '_sir_'. Don't write unnecessary comments;
-don't be over-apologetic. There is no superiority hierarchy. Every
-single contribution is welcome, as long as it doesn't spam or distract
-the flow.
+   to address anyone using '_sir_'. Don't write unnecessary comments;
+   don't be over-apologetic. There is no superiority hierarchy. Every
+   single contribution is welcome, as long as it doesn't spam or distract
+   the flow.
 
 6. Write useful, brief commit messages. Add commit descriptions if
-necessary. PR name should speak about what it is addressing and not
-the issue. In case a PR fixes an issue, use `fixes #ticketno` or
-`closes #ticketno` in the PR's comment. Briefly explain what your PR
-is doing.
+   necessary. PR name should speak about what it is addressing and not
+   the issue. In case a PR fixes an issue, use `fixes #ticketno` or
+   `closes #ticketno` in the PR's comment. Briefly explain what your PR
+   is doing.
 
 7. Always test your changes extensively before creating a PR. There's
-no sense in merging broken code. If a PR is a _work in progress
-(WIP)_, convert it to draft. It'll let the maintainers know it isn't
-ready for merging.
+   no sense in merging broken code. If a PR is a _work in progress
+   (WIP)_, convert it to draft. It'll let the maintainers know it isn't
+   ready for merging.
 
 8. Read and revise the concepts about programming constructs you're
-dealing with. You must be clear about the behavior of the language or
-compiler/transpiler. See [JavaScript
-docs](https://developer.mozilla.org/en-US/docs/Web/JavaScript).
+   dealing with. You must be clear about the behavior of the language or
+   compiler/transpiler. See [JavaScript
+   docs](https://developer.mozilla.org/en-US/docs/Web/JavaScript).
 
 9. If you have a question, do a _web search_ first. If you don't find
-any satisfactory answer, then ask it in a comment. If it is a general
-question about Music Blocks, please use the new
-[discussions](https://github.com/sugarlabs/musicblocks/discussions)
-tab on top the the repository, or the _Sugar-dev Devel
-<[sugar-devel@lists.sugarlabs.org](mailto:sugar-devel@lists.sugarlabs.org)>_
-mailing list. Don't ask silly questions (unless you don't know it is
-silly ;p) before searching it on the web.
+   any satisfactory answer, then ask it in a comment. If it is a general
+   question about Music Blocks, please use the new
+   [discussions](https://github.com/sugarlabs/musicblocks/discussions)
+   tab on top the the repository, or the _Sugar-dev Devel
+   <[sugar-devel@lists.sugarlabs.org](mailto:sugar-devel@lists.sugarlabs.org)>_
+   mailing list. Don't ask silly questions (unless you don't know it is
+   silly ;p) before searching it on the web.
 
 10. Work on things that matter. Follow three milestones: `Port Ready`,
-`Migration`, and `Future`.  Those tagged `Port Ready` are
-priority. Those tagged with `Migration` will be taken care of during
-or after the foundation rebuild. Feel free to participate in the
-conversation, adding valuable comments. Those tagged with `Future`
-need not be addressed presently.
+    `Migration`, and `Future`. Those tagged `Port Ready` are
+    priority. Those tagged with `Migration` will be taken care of during
+    or after the foundation rebuild. Feel free to participate in the
+    conversation, adding valuable comments. Those tagged with `Future`
+    need not be addressed presently.
 
 _Please note there is no need to ask permission to work on an
 issue. You should check for pull requests linked to an issue you are
 addressing; if there are none, then assume nobody has done
 anything. Begin to fix the problem, test, make your commits, push your
 commits, then make a pull request. Mention an issue number in the pull
 request, but not the commit message. These practices allow the
-competition of ideas (Sugar Labs is a meritocracy)._
+competition of ideas (Sugar Labs is a meritocracy)._