From 49234c588a5a1dbf638b01d208a95d73efad5dce Mon Sep 17 00:00:00 2001
From: Lalit Narayan Yadav
 <162928571+LalitNarayanYadav@users.noreply.github.com>
Date: Sat, 7 Jun 2025 06:04:54 +0530
Subject: [PATCH 1/7] docs: replace deprecated grunt commands with npm/vitest
 scripts in docs #7871

---
 contributor_docs/steward_guidelines.md | 82 +++++++++++++++-----------
 1 file changed, 49 insertions(+), 33 deletions(-)

diff --git a/contributor_docs/steward_guidelines.md b/contributor_docs/steward_guidelines.md
index 98cbdbebdc..21b38109c2 100644
--- a/contributor_docs/steward_guidelines.md
+++ b/contributor_docs/steward_guidelines.md
@@ -175,55 +175,68 @@ Dependabot PRs are usually only visible to repo admins so if this does not apply
 
 This section will not cover the general build setup nor commands but rather details about what's happening behind the scenes. Please see the [contributor’s guidelines](contributor_guidelines.md#working-on-p5js-codebase) for more detailed build info.
 
-The Gruntfile.js file contains the main build definitions for p5.js. Among the different tools used to build the library and documentation includes but not limited to Grunt, Browserify, YUIDoc, ESLint, Babel, Uglify, and Mocha. It may be helpful for us to start with the `default` task and work backward from there. It may be helpful at this point to open up the Gruntfile.js document while going through the explainer below.
+Starting with p5.js version 2.0, the project no longer uses Grunt for task automation. Instead, the build and test processes are handled using modern tools like npm scripts, ESLint, and [Vitest](https://vitest.dev/).
 
 
 ### Main build task
 
+To run lint checks and unit tests, simply run:
+
 ```
-grunt.registerTask('default', ['lint', 'test']);
+npm test
 ```
 
-When we run `grunt` or the npm script `npm test`, we run the default task consisting of `lint` then `test`.
-
+This command will run ESLint to check code style and then execute unit and visual tests using Vitest.
 
 #### `lint` Task
 
+In p5.js 2.0, ESLint is used directly via npm scripts for all linting tasks.
+
+To run lint checks on the codebase:
+
 ```
-grunt.registerTask('lint', ['lint:source', 'lint:samples']);
+npm run lint
 ```
 
-The `lint` task consists of two sub tasks: `lint:source` and `lint:samples`. `lint:source` is further subdivided into three more sub tasks `eslint:build`, `eslint:source`, and `eslint:test`, which uses ESLint to check the build scripts, the source code, and the test scripts.
+This checks the source files, build scripts, test files, and documentation examples using ESLint.
 
-The `lint:samples` task will first run the `yui` task which itself consists of `yuidoc:prod`, `clean:reference`, and `minjson`, which extract the documentation from the source code into a JSON document, remove unused files from the previous step, and minify the generated JSON file into `data.min.json` respectively.
+If you only want to run linting for specific files or directories, you can use ESLint directly:
 
-Next in `lint:samples` is `eslint-samples:source`, which is a custom written task whose definition is in [../tasks/build/eslint-samples.js](../tasks/build/eslint-samples.js); it will run ESLint to check the documentation example code to make sure they follow the same coding convention as the rest of p5.js (`yui` is run first here because we need the JSON file to be built first before we can lint the examples).
+```
+npx eslint src/
+npx eslint test/
+```
 
+There is no separate sample linter or YUIDoc-based pipeline anymore, as documentation is now managed through simpler, modern tooling.
 
 #### `test` Task
 
-```js
-grunt.registerTask('test', [
-  'build',
-  'connect:server',
-  'mochaChrome',
-  'mochaTest',
-  'nyc:report'
-]);
+In p5.js 2.0, the testing system no longer uses Mocha via Grunt. Instead, tests are run using [Vitest](https://vitest.dev/) through npm scripts.
+
+To run the full test suite (unit and visual tests), use:
+
 ```
+npm test
+```
+
+This command performs:
+- Linting via ESLint
+- Unit tests using Vitest
+- Visual tests (render-based snapshots)
 
-First let's look at the `build` task under `test`.
+Tests are located in the `test/unit` folder, organized to mirror the `src` directory structure. For example, tests for `src/color/p5.Color.js` live in `test/unit/color/p5.Color.js`.
 
-```js
-grunt.registerTask('build', [
-  'browserify',
-  'browserify:min',
-  'uglify',
-  'browserify:test'
-]);
+To run tests interactively in a browser-like environment (useful for debugging), run:
+
+```
+npx vitest --ui
 ```
 
-Tasks that start with `browserify` are defined in [../tasks/build/browserify.js](../tasks/build/browserify.js). They all have similar steps with minor differences. These are the main steps to build the full p5.js library from its many source code files into one:
+Code coverage is also supported using Vitest's built-in tools. Run:
+
+```
+npx vitest run --coverage
+```
 
 - `browserify` builds p5.js while `browserify:min` builds an intermediate file to be minified in the next step. The difference between `browserify` and `browserify:min` is that `browserify:min` does not contain data needed for FES to function.
 - `uglify` takes the output file of `browserify:min` and minify it into the final p5.min.js (configuration of this step is in the main Gruntfile.js).
@@ -266,22 +279,25 @@ And that covers the default task in the Gruntfile.js configuration!
 
 ### Miscellaneous tasks
 
-All of the steps can be run directly with `npx grunt [step]`. There are also a few tasks that are not covered above but could be useful in certain cases.
+All of the steps can now be run using npm scripts or directly with Vitest. The Grunt build system and tasks have been removed in the dev-2.0 branch.
+
+You can use the equivalent npm script or local development commands (please refer to the package.json scripts section).
+
+For testing, run:
 
 ```
-grunt yui:dev
+npm test
 ```
 
-This task will run the documentation and library builds described above, followed by spinning up a web server that serves a functionally similar version of the reference page you will find on the website on [http://localhost:9001/docs/reference/](http://localhost:9001/docs/reference/). It will then monitor the source code for changes and rebuild the documentation and library.
-
-`grunt` `yui:dev` is useful when you are working on the reference in the inline documentation because you don't have to move built files from the p5.js repository to a local p5.js-website repository and rebuild the website each time you make a change, and you can just preview your changes with this slightly simplified version of the reference in your browser. This way, you can also be more confident that the changes you made are likely to show up correctly on the website. Note that this is only meant for modifications to the inline documentation; changes to the reference page itself, including styling and layout, should be made and tested on the website repository.
+For running watchers, use:
 
 ```
-grunt watch
-grunt watch:main
-grunt watch:quick
+npm run watch
 ```
 
+Note: The previous `grunt yui:dev` task that served the documentation locally and watched for changes is replaced by modern tooling; please check the updated documentation or package.json for exact commands to serve and watch.
+
+
 The watch tasks will watch a series of files for changes and run associated tasks to build the reference or the library according to what files have changed. These tasks all do the same thing, with the only difference being the scope.
 
 The `watch` task will run all builds and tests similar to running the full default task on detecting changes in the source code.

From 083bae8824c83b54b1b63a1381f6ba0b6e545231 Mon Sep 17 00:00:00 2001
From: Lalit Narayan Yadav
 <162928571+LalitNarayanYadav@users.noreply.github.com>
Date: Sat, 7 Jun 2025 15:19:56 +0530
Subject: [PATCH 2/7] docs: replace outdated Grunt commands with npm/Vitest
 equivalents in test section #7871

---
 contributor_docs/es/steward_guidelines.md | 36 +++++++++--------------
 1 file changed, 14 insertions(+), 22 deletions(-)

diff --git a/contributor_docs/es/steward_guidelines.md b/contributor_docs/es/steward_guidelines.md
index de1ef0f477..679c271dc2 100644
--- a/contributor_docs/es/steward_guidelines.md
+++ b/contributor_docs/es/steward_guidelines.md
@@ -180,7 +180,7 @@ El archivo Gruntfile.js contiene las definiciones principales de construcción p
 ### Tarea Principal de Construcción
 
 ```
-grunt.registerTask('default', ['lint', 'test']);
+npm test
 ```
 
 Cuando ejecutamos `grunt` o el script npm `npm test`, ejecutamos la tarea predeterminada que consiste en `lint` y luego `test`.
@@ -189,7 +189,7 @@ Cuando ejecutamos `grunt` o el script npm `npm test`, ejecutamos la tarea predet
 #### Tarea `lint`
 
 ```
-grunt.registerTask('lint', ['lint:source', 'lint:samples']);
+npm run lint
 ```
 
 La tarea `lint` consiste en dos sub tareas: `lint:source` y `lint:samples`. `lint:source` está subdividida aún más en tres sub tareas adicionales: `eslint:build`, `eslint:source` y `eslint:test`, que utilizan ESLint para verificar los scripts de construcción, el código fuente y los scripts de prueba.
@@ -201,26 +201,20 @@ A continuación en `lint:samples` está `eslint-samples:source`, que es una tare
 
 #### Tarea `test`
 
-```js
-grunt.registerTask('test', [
-  'build',
-  'connect:server',
-  'mochaChrome',
-  'mochaTest',
-  'nyc:report'
-]);
+En la rama `dev-2.0`, la tarea `test` de Grunt ha sido reemplazada por un comando moderno de `npm`:
+
+```
+npm test
 ```
 
-Primero, veamos la tarea `build` dentro de `test`.
+Este comando ejecuta la suite de pruebas completa usando [Vitest](https://vitest.dev/), e incluye cobertura y pruebas en múltiples entornos según sea necesario.
+
 
-```js
-grunt.registerTask('build', [
-  'browserify',
-  'browserify:min',
-  'uglify',
-  'browserify:test'
-]);
 ```
+npm run build
+```
+
+Este comando construye la biblioteca `p5.js` utilizando herramientas modernas como [Vite](https://vitejs.dev/) o configuraciones personalizadas según `package.json`. Sustituye completamente los pasos anteriores que usaban `browserify` y `uglify`.
 
 Las tareas que comienzan con `browserify` están definidas en [./tasks/build/browserify.js](tasks/build/browserify.js). Todas siguen pasos similares con diferencias menores. Estos son los pasos principales para construir la biblioteca completa de p5.js a partir de sus numerosos archivos fuente en uno solo:
 
@@ -270,7 +264,7 @@ Finalmente, después de que todas las construcciones y pruebas estén completas,
 Todos los pasos pueden ejecutarse directamente con `npx grunt [step]`. También hay algunas tareas que no se mencionan arriba pero podrían ser útiles en ciertos casos.
 
 ```
-grunt yui:dev
+npm test
 ```
 
 Esta tarea ejecutará las construcciones de documentación y biblioteca descritas arriba, seguidas de la puesta en marcha de un servidor web que sirve una versión funcionalmente similar de la página de referencia que encontrarás en el sitio web en [http://localhost:9001/docs/reference/](http://localhost:9001/docs/reference/). Luego, supervisará el código fuente en busca de cambios y reconstruirá la documentación y la biblioteca.
@@ -278,9 +272,7 @@ Esta tarea ejecutará las construcciones de documentación y biblioteca descrita
 `grunt` `yui:dev` es útil cuando estás trabajando en la referencia en la documentación en línea porque no necesitas mover archivos construidos del repositorio de p5.js a un repositorio local de un sitio de p5.js y reconstruir el sitio web cada vez que hagas un cambio, y puedes previsualizar tus cambios con esta versión ligeramente simplificada de la referencia en tu navegador. De esta manera, también puedes tener más confianza en que los cambios que hiciste probablemente se mostrarán correctamente en el sitio web. Ten en cuenta que esto solo está destinado a modificaciones en la documentación en línea; los cambios en la página de referencia en sí, incluido el estilo y el diseño, deben hacerse y probarse en el repositorio del sitio web.
 
 ```
-grunt watch
-grunt watch:main
-grunt watch:quick
+npm run watch
 ```
 
 Las tareas de observación vigilarán una serie de archivos en busca de cambios y ejecutarán tareas asociadas para construir la referencia o la biblioteca según los archivos que hayan cambiado. Estas tareas hacen lo mismo, la única diferencia es el alcance.

From 88eff1b5a998054f30886ad55d5964373cac59d3 Mon Sep 17 00:00:00 2001
From: Lalit Narayan Yadav
 <162928571+LalitNarayanYadav@users.noreply.github.com>
Date: Sat, 7 Jun 2025 15:36:28 +0530
Subject: [PATCH 3/7] docs: revise build instructions to remove Grunt commands

---
 contributor_docs/archive/custom_p5_build.md | 21 ++++++---------------
 1 file changed, 6 insertions(+), 15 deletions(-)

diff --git a/contributor_docs/archive/custom_p5_build.md b/contributor_docs/archive/custom_p5_build.md
index 04eab00f67..6faf80c2a0 100644
--- a/contributor_docs/archive/custom_p5_build.md
+++ b/contributor_docs/archive/custom_p5_build.md
@@ -10,29 +10,20 @@ This feature was suggested as a part of a proposal for Google Summer of Code 201
 
 ## Usage
 
-Currently, the usage is through invoking a Grunt task manually from the command line:
+
+p5.js has migrated to modern tooling. Use the following to build and test:
 
 ```sh
 git clone https://github.com/processing/p5.js.git
 cd p5.js
 npm ci
-npm run grunt
-npm run grunt combineModules:module_x:module_y
+npm run build      # builds the full p5.js bundle
+npm test           # runs linter and tests using Vitest
 ```
 
-Here, `module_n` refers to the name of the modules which you want to select. Multiple modules must be passed as shown above. Also, these modules must have the same name as their folders in `/src` directory to work correctly. While `core` is included by default, `core/shape` needs to be included for shapes like line() and other core features to work.
-
-The above usage example will likely output a `p5Custom.js` larger than the complete `p5.min.js` as the output is not minified using the `uglify` task.
+To include only selected modules in a custom build, refer to the CONTRIBUTING guide or module-specific documentation. Rollup or tree-shaking through ES modules may be used for advanced setups.
 
-The recommended steps to reduce bundle size as much as possible are:
-
-```sh
-git clone https://github.com/processing/p5.js.git
-cd p5.js
-npm ci
-npm run grunt
-npm run grunt combineModules:min:module_x:module_y uglify
-```
+---
 
 ## Examples
 

From 5915e7a2676edf48b28ef082ea44f284b141d7be Mon Sep 17 00:00:00 2001
From: Lalit Narayan Yadav
 <162928571+LalitNarayanYadav@users.noreply.github.com>
Date: Thu, 12 Jun 2025 18:26:31 +0530
Subject: [PATCH 4/7] docs: correct lint/test commands and remove misleading
 npm test line from custom_p5_build.md

---
 contributor_docs/archive/custom_p5_build.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contributor_docs/archive/custom_p5_build.md b/contributor_docs/archive/custom_p5_build.md
index 6faf80c2a0..d8dfdc0033 100644
--- a/contributor_docs/archive/custom_p5_build.md
+++ b/contributor_docs/archive/custom_p5_build.md
@@ -18,7 +18,7 @@ git clone https://github.com/processing/p5.js.git
 cd p5.js
 npm ci
 npm run build      # builds the full p5.js bundle
-npm test           # runs linter and tests using Vitest
+npm run lint           # runs linter and tests using Vitest
 ```
 
 To include only selected modules in a custom build, refer to the CONTRIBUTING guide or module-specific documentation. Rollup or tree-shaking through ES modules may be used for advanced setups.

From 85e2e34e0ca7535fde6207eeaf9d4ea3db769729 Mon Sep 17 00:00:00 2001
From: Perminder Singh <127239756+perminder-17@users.noreply.github.com>
Date: Mon, 3 Nov 2025 01:33:00 +0530
Subject: [PATCH 5/7] Delete contributor_docs/archive/custom_p5_build.md

---
 contributor_docs/archive/custom_p5_build.md | 37 ---------------------
 1 file changed, 37 deletions(-)
 delete mode 100644 contributor_docs/archive/custom_p5_build.md

diff --git a/contributor_docs/archive/custom_p5_build.md b/contributor_docs/archive/custom_p5_build.md
deleted file mode 100644
index d8dfdc0033..0000000000
--- a/contributor_docs/archive/custom_p5_build.md
+++ /dev/null
@@ -1,37 +0,0 @@
-<!-- Instructions on how to combine just the p5.js modules you need into a single file. -->
-
-# Creating a custom build of p5.js with select components
-
-## Overview
-
-An excellent new [feature](https://github.com/processing/p5.js/pull/2051) of p5.js allows user to build p5.js as a custom combination of its modules. This greatly helps in reducing the production version size of the library, as well as improves overall performance.
-
-This feature was suggested as a part of a proposal for Google Summer of Code 2017.
-
-## Usage
-
-
-p5.js has migrated to modern tooling. Use the following to build and test:
-
-```sh
-git clone https://github.com/processing/p5.js.git
-cd p5.js
-npm ci
-npm run build      # builds the full p5.js bundle
-npm run lint           # runs linter and tests using Vitest
-```
-
-To include only selected modules in a custom build, refer to the CONTRIBUTING guide or module-specific documentation. Rollup or tree-shaking through ES modules may be used for advanced setups.
-
----
-
-## Examples
-
-- `npm run grunt combineModules:min:core/shape:color:math:image uglify`  
-  Generates a `p5Custom.min.js` bundle in the `lib/modules` directory with the combineModules and uglify tasks. Note that modules should be listed after `combineModules:min` and the `uglify` task should have a space after the modules list.
-
-- `npm run grunt combineModules:core/shape:color:math:image`  
-  Generates a non-minified `p5Custom.js` bundle in the `lib/modules` directory.
-
-- `npm run grunt combineModules:min:core/shape:color:math:image`  
-  Generates a `p5Custom.pre-min.js` in the `lib/modules` directory with the `combineModules:min` task. Note that in this example `npm run grunt uglify` can be run separately after running the `combineModules:min` task.

From 16f239d2ab4f92aa469ca27a5af2ea7cf43b1459 Mon Sep 17 00:00:00 2001
From: Perminder Singh <127239756+perminder-17@users.noreply.github.com>
Date: Mon, 3 Nov 2025 04:39:53 +0530
Subject: [PATCH 6/7] Removing grunt

---
 contributor_docs/steward_guidelines.md | 83 ++------------------------
 1 file changed, 5 insertions(+), 78 deletions(-)

diff --git a/contributor_docs/steward_guidelines.md b/contributor_docs/steward_guidelines.md
index 16479d3dd6..2782279b7e 100644
--- a/contributor_docs/steward_guidelines.md
+++ b/contributor_docs/steward_guidelines.md
@@ -20,11 +20,10 @@ Whether you are new to p5.js contribution, are already active on the p5.js GitHu
 - [Pull Requests](#pull-requests)
   - [Simple fix](#simple-fix)
   - [Bug fix](#bug-fix)
-  - [New feature/feature enhancement](#new-feature-feature-enhancement)
+  - [New feature/feature enhancement](#new-featurefeature-enhancement)
   - [Dependabot](#dependabot)
 - [Build Process](#build-process)
   - [Main build task](#main-build-task)
-  - [Miscellaneous tasks](#miscellaneous-tasks)
 - [Release Process](#release-process)
 - [Tips & Tricks](#tips--tricks)
   - [Reply templates](#reply-templates)
@@ -87,7 +86,7 @@ To remain a steward, you must contribute as a steward to at least 1 of the 2 mos
 
 ### Getting Started with Stewardship
 
-1. Keep this guideline handy as a reference - how to help with new issues, bugs, and features. For example, the "Feature request" section includes tips on how to use the the p5.js [access statement](access.md) as a steward.
+1. Keep this guideline handy as a reference - how to help with new issues, bugs, and features. For example, the "Feature request" section includes tips on how to use the p5.js [access statement](access.md) as a steward.
 2. When helping to answer technical questions or review, try to apply the Processing Foundation [guideline on answering questions](https://discourse.processing.org/t/guidelines-answering-questions/2145) - these can be especially helpful for giving constructive technical feedback.
 3. Join the [p5.js Discord](https://discord.com/invite/SHQ8dH25r9)  - in the `#contribute-to-p5` you're welcome to ask any questions you have about this process - or suggest how it can be improved!
 
@@ -248,7 +247,7 @@ To run lint checks and unit tests, simply run:
 npm test
 ```
 
-This command will run ESLint to check code style and then execute unit and visual tests using Vitest.
+This command runs ESLint to check code style and then execute unit and visual tests using Vitest.
 
 #### `lint` Task
 
@@ -269,7 +268,7 @@ npx eslint src/
 npx eslint test/
 ```
 
-There is no separate sample linter or YUIDoc-based pipeline anymore, as documentation is now managed through simpler, modern tooling.
+There is no separate sample linter or YUIDoc-based pipeline anymore.
 
 #### `test` Task
 
@@ -300,78 +299,7 @@ Code coverage is also supported using Vitest's built-in tools. Run:
 npx vitest run --coverage
 ```
 
-- `browserify` builds p5.js while `browserify:min` builds an intermediate file to be minified in the next step. The difference between `browserify` and `browserify:min` is that `browserify:min` does not contain data needed for FES to function.
-- `uglify` takes the output file of `browserify:min` and minify it into the final p5.min.js (configuration of this step is in the main Gruntfile.js).
-- `browserify:test` is building a version identical to the full p5.js except for added code that is used for test code coverage reporting (using [Istanbul](https://istanbul.js.org/)).
-
-First, use of the `fs.readFileSync()` node.js specific code is replaced with the file's actual content using `brfs-babel`. This is used mainly by WebGL code to inline shader code from source code written as separate files.
-
-Next, the source code, including all dependencies from node\_modules, is transpiled using Babel to match the [Browserslist](https://browsersl.ist/) requirement defined in package.json as well as to make the ES6 import statements into CommonJS `require()` that browserify understands. This also enables us to use newer syntax available in ES6 and beyond without worrying about browser compatibility.
-
-After bundling but before the bundled code is written to file, the code is passed through `pretty-fast`, if it is not meant to be minified, it should be cleaned up so the final formatting is a bit more consistent (we anticipate the p5.js source code can be read and inspected if desired).
-
-A few small detailed steps are left out here; you can check out the browserify build definition file linked above to have a closer look at everything.
-
-```
-connect:server
-```
-
-This step spins up a local server hosting the test files and built source code files so that automated tests can be run in Chrome.
-
-```
-mochaChrome
-```
-
-This step is defined in [../tasks/test/mocha-chrome.js](../tasks/test/mocha-chrome.js). It uses Puppeteer to spin up a headless version of Chrome that can be remote controlled and runs the tests associated with the HTML files in the `./test` folder, which includes testing the unminified and minified version of the library against the unit test suites as well as testing all reference examples.
-
-```
-mochaTest
-```
-
-This step differs from `mochaChrome` in that it is run in node.js instead of in Chrome and only tests a small subset of features in the library. Most features in p5.js will require a browser environment, so this set of tests should only be expanded if the new tests really don't need a browser environment.
-
-```
-nyc:report
-```
-
-Finally, after all builds and tests are complete, this step will gather the test coverage report while `mochaChrome` was testing the full version of the library and print the test coverage data to the console. Test coverage for p5.js is mainly for monitoring and having some additional data points; having 100% test coverage is not a goal.
-
-And that covers the default task in the Gruntfile.js configuration!
-
-
-### Miscellaneous tasks
-
-All of the steps can now be run using npm scripts or directly with Vitest. The Grunt build system and tasks have been removed in the dev-2.0 branch.
-
-You can use the equivalent npm script or local development commands (please refer to the package.json scripts section).
-
-For testing, run:
-
-```
-npm test
-```
-
-For running watchers, use:
-
-```
-npm run watch
-```
-
-Note: The previous `grunt yui:dev` task that served the documentation locally and watched for changes is replaced by modern tooling; please check the updated documentation or package.json for exact commands to serve and watch.
-
-
-The watch tasks will watch a series of files for changes and run associated tasks to build the reference or the library according to what files have changed. These tasks all do the same thing, with the only difference being the scope.
-
-The `watch` task will run all builds and tests similar to running the full default task on detecting changes in the source code.
-
-The `watch:main` task will run the library build and tests but not rebuild the reference on detecting changes in the source code.
-
-The `watch:quick` task will run the library build only on detecting changes in the source code.
-
-Depending on what you are working on, choosing the most minimal watch task here can save you from having to manually run a rebuild whenever you want to make some changes.
-
----
-
+**Note:** The Browserify/Grunt build pipeline (e.g., `browserify`, `uglify`, `brfs-babel`) was removed in v2.  
 
 ## Release process
 
@@ -459,4 +387,3 @@ By watching a repo, events such as new issues, new pull requests, mentions of yo
 In some cases, you may receive emails from GitHub about events in the repo you are watching as well, and you can customize these (including unsubscribing from them completely) from your [notifications settings page](https://github.com/settings/notifications).
 
 Setting these up to fit the way you work can be the difference between having to find relevant issues/PRs to review manually and being overwhelmed by endless notifications from GitHub. A good balance is required here. As a starting suggestion, stewards should watch this repo for "Issues" and "Pull Requests" and set it to only receive emails on "Participating, @mentions and custom."
-

From 79eba678b77667cd081c113785aad6457452e792 Mon Sep 17 00:00:00 2001
From: Perminder Singh <127239756+perminder-17@users.noreply.github.com>
Date: Mon, 3 Nov 2025 04:42:44 +0530
Subject: [PATCH 7/7] Reverting changes

---
 contributor_docs/es/steward_guidelines.md | 37 ++++++++++++++---------
 1 file changed, 22 insertions(+), 15 deletions(-)

diff --git a/contributor_docs/es/steward_guidelines.md b/contributor_docs/es/steward_guidelines.md
index 679c271dc2..3a2c9f4fba 100644
--- a/contributor_docs/es/steward_guidelines.md
+++ b/contributor_docs/es/steward_guidelines.md
@@ -180,7 +180,7 @@ El archivo Gruntfile.js contiene las definiciones principales de construcción p
 ### Tarea Principal de Construcción
 
 ```
-npm test
+grunt.registerTask('default', ['lint', 'test']);
 ```
 
 Cuando ejecutamos `grunt` o el script npm `npm test`, ejecutamos la tarea predeterminada que consiste en `lint` y luego `test`.
@@ -189,7 +189,7 @@ Cuando ejecutamos `grunt` o el script npm `npm test`, ejecutamos la tarea predet
 #### Tarea `lint`
 
 ```
-npm run lint
+grunt.registerTask('lint', ['lint:source', 'lint:samples']);
 ```
 
 La tarea `lint` consiste en dos sub tareas: `lint:source` y `lint:samples`. `lint:source` está subdividida aún más en tres sub tareas adicionales: `eslint:build`, `eslint:source` y `eslint:test`, que utilizan ESLint para verificar los scripts de construcción, el código fuente y los scripts de prueba.
@@ -201,20 +201,26 @@ A continuación en `lint:samples` está `eslint-samples:source`, que es una tare
 
 #### Tarea `test`
 
-En la rama `dev-2.0`, la tarea `test` de Grunt ha sido reemplazada por un comando moderno de `npm`:
-
-```
-npm test
+```js
+grunt.registerTask('test', [
+  'build',
+  'connect:server',
+  'mochaChrome',
+  'mochaTest',
+  'nyc:report'
+]);
 ```
 
-Este comando ejecuta la suite de pruebas completa usando [Vitest](https://vitest.dev/), e incluye cobertura y pruebas en múltiples entornos según sea necesario.
-
+Primero, veamos la tarea `build` dentro de `test`.
 
+```js
+grunt.registerTask('build', [
+  'browserify',
+  'browserify:min',
+  'uglify',
+  'browserify:test'
+]);
 ```
-npm run build
-```
-
-Este comando construye la biblioteca `p5.js` utilizando herramientas modernas como [Vite](https://vitejs.dev/) o configuraciones personalizadas según `package.json`. Sustituye completamente los pasos anteriores que usaban `browserify` y `uglify`.
 
 Las tareas que comienzan con `browserify` están definidas en [./tasks/build/browserify.js](tasks/build/browserify.js). Todas siguen pasos similares con diferencias menores. Estos son los pasos principales para construir la biblioteca completa de p5.js a partir de sus numerosos archivos fuente en uno solo:
 
@@ -264,7 +270,7 @@ Finalmente, después de que todas las construcciones y pruebas estén completas,
 Todos los pasos pueden ejecutarse directamente con `npx grunt [step]`. También hay algunas tareas que no se mencionan arriba pero podrían ser útiles en ciertos casos.
 
 ```
-npm test
+grunt yui:dev
 ```
 
 Esta tarea ejecutará las construcciones de documentación y biblioteca descritas arriba, seguidas de la puesta en marcha de un servidor web que sirve una versión funcionalmente similar de la página de referencia que encontrarás en el sitio web en [http://localhost:9001/docs/reference/](http://localhost:9001/docs/reference/). Luego, supervisará el código fuente en busca de cambios y reconstruirá la documentación y la biblioteca.
@@ -272,7 +278,9 @@ Esta tarea ejecutará las construcciones de documentación y biblioteca descrita
 `grunt` `yui:dev` es útil cuando estás trabajando en la referencia en la documentación en línea porque no necesitas mover archivos construidos del repositorio de p5.js a un repositorio local de un sitio de p5.js y reconstruir el sitio web cada vez que hagas un cambio, y puedes previsualizar tus cambios con esta versión ligeramente simplificada de la referencia en tu navegador. De esta manera, también puedes tener más confianza en que los cambios que hiciste probablemente se mostrarán correctamente en el sitio web. Ten en cuenta que esto solo está destinado a modificaciones en la documentación en línea; los cambios en la página de referencia en sí, incluido el estilo y el diseño, deben hacerse y probarse en el repositorio del sitio web.
 
 ```
-npm run watch
+grunt watch
+grunt watch:main
+grunt watch:quick
 ```
 
 Las tareas de observación vigilarán una serie de archivos en busca de cambios y ejecutarán tareas asociadas para construir la referencia o la biblioteca según los archivos que hayan cambiado. Estas tareas hacen lo mismo, la única diferencia es el alcance.
@@ -374,4 +382,3 @@ Al observar un repositorio, eventos como nuevos <em>issues</em>, nuevos <em>pull
 En algunos casos, también puedes recibir correos electrónicos de GitHub sobre eventos en el repositorio que estás observando, y puedes personalizarlos (incluida la desuscripción completa de ellos) desde tu [página de configuración de notificaciones](https://github.com/settings/notifications).
 
 Configurar estas opciones para que se adapten a la forma en que trabajas puede ser la diferencia entre tener que buscar <em>issues</em>/PRs relevantes para revisar manualmente y sentirse abrumado por notificaciones interminables de GitHub. Se requiere un buen equilibrio aquí. Como sugerencia inicial, los supervisores deberían observar este repositorio para <em>Issues</em> y <em>Pull Requests</em> y configurarlo para recibir correos electrónicos solo sobre "Participando, @menciones y personalizadas".
-