Merge branch 'dev-2.0' into fix/font-align

Author: davepagurek

contributor_docs/es/steward_guidelines.md

@@ -4,7 +4,6 @@
 
 Ya sea que seas nuevo contribuyendo para p5.js, que seas activo en los repositorios de GitHub de p5.js, o que te encuentres en algún punto intermedio, encontrarás lo que necesitas en estas directrices sobre el rol de steward (guía de área) en p5.js. Si no estás seguro de qué esperar de los stewards, o si estás considerando ofrecerte como voluntario o comenzar como steward, ¡sigue leyendo!
 
-
 ## Tabla de Contenidos
 
 - [Stewardship (Guía de Área)](#stewardship)
@@ -229,131 +228,73 @@ Las _pull requests_ de Dependabot generalmente solo son visibles para los admini
 
 ---
 
+## Proceso de Compilación
 
-## Proceso de Construcción
-
-Esta sección no cubrirá la configuración general de construcción ni los comandos, sino más bien detalles sobre lo que sucede detrás de escena. Consulta las [directrices para administradores](contributor_guidelines.md#working-on-p5js-codebase) para obtener información más detallada sobre la construcción.
-
-El archivo Gruntfile.js contiene las definiciones principales de construcción para p5.js. Entre las diferentes herramientas utilizadas para construir la biblioteca y la documentación se incluyen, pero no se limitan a: Grunt, Browserify, YUIDoc, ESLint, Babel, Uglify y Mocha. Puede ser útil comenzar con la tarea `default` y retroceder desde allí. También puede ser útil abrir el documento Gruntfile.js mientras se sigue la explicación a continuación.
+Esta sección no cubrirá la configuración general de compilación (build) ni los comandos, sino más bien detalles sobre lo que sucede detrás de escena. Consulta las [directrices para administradores](contributor_guidelines.md#working-on-p5js-codebase) para obtener información más detallada sobre la construcción.
 
+A partir de la versión 2.0 de p5.js, el proyecto ya no usa Grunt para la automatización de tareas. En su lugar, los procesos de compilación y pruebas (test) se manejan usando herramientas modernas como scripts de npm, ESLint y [Vitest](https://vitest.dev/).
 
 ### Tarea Principal de Construcción
 
-```
-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`.
-
-
-#### Tarea `lint`
+Para ejecutar las verificaciones de estilo del código (lint) y las pruebas unitarias (unit tests), simplemente ejecuta:
 
 ```
-grunt.registerTask('lint', ['lint:source', 'lint:samples']);
+npm test
 ```
 
-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.
+Este comando ejecuta ESLint para verificar el estilo del código y luego ejecuta las pruebas unitarias y las pruebas visuales usando Vitest.
 
-La tarea `lint:samples` primero ejecutará la tarea `yui`, que a su vez consiste en `yuidoc:prod`, `clean:reference` y `minjson`, que extraen la documentación del código fuente en un documento JSON, eliminan archivos no utilizados del paso anterior y minifican el archivo JSON generado en `data.min.json, respectivamente.
-
-A continuación en `lint:samples` está `eslint-samples:source`, que es una tarea escrita personalizada cuya definición está en [./tasks/build/eslint-samples.js](tasks/build/eslint-samples.js); ejecutará ESLint para verificar el código de ejemplo de la documentación y asegurarse de que siga la misma convención de codificación que el resto de p5.js (`yui` se ejecuta primero aquí porque necesitamos que el archivo JSON se construya primero antes de que podamos aplicar lint a los ejemplos).
+#### Tarea `lint`
 
+En p5.js 2.0, ESLint se usa directamente mediante scripts de npm para todas las tareas de verificación de estilo (linting).
 
-#### Tarea `test`
+Para ejecutar las verificaciones de estilo (lint) en el código del proyecto.
 
-```js
-grunt.registerTask('test', [
-  'build',
-  'connect:server',
-  'mochaChrome',
-  'mochaTest',
-  'nyc:report'
-]);
 ```
-
-Primero, veamos la tarea `build` dentro de `test`.
-
-```js
-grunt.registerTask('build', [
-  'browserify',
-  'browserify:min',
-  'uglify',
-  'browserify:test'
-]);
+npm run lint
 ```
 
-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:
-
-- `browserify` construye p5.js, mientras que `browserify:min` construye un archivo intermedio para ser minificado en el siguiente paso. La diferencia entre `browserify` y `browserify:min` es que `browserify:min` no contiene datos necesarios para que funcione FES.
-- `uglify` toma el archivo de salida de `browserify:min` y lo minifica en el p5.min.js final (la configuración de este paso está en el archivo Gruntfile.js principal).
-- `browserify:test` está construyendo una versión idéntica y completa a la de p5.js, salvo por el código adicional que se utiliza para informar sobre la cobertura de código de prueba (usando [Istanbul](https://istanbul.js.org/)).
-
-Primero, el uso del código específico de node.js `fs.readFileSync()` es reemplazado por el contenido real del archivo utilizando `brfs-babel`. Esto se utiliza principalmente en el código WebGL para insertar código de <em>shader</em> desde archivos fuente escritos como archivos separados.
-
-A continuación, el código fuente, incluidas todas las dependencias de node\_modules, se transpila usando Babel para cumplir con el requisito de [Browserslist](https://browsersl.ist/) definido en package.json, así como para convertir las declaraciones de importación ES6 en `require()` de CommonJS que browserify comprende. Esto también nos permite utilizar una sintaxis más nueva disponible en ES6 y más allá sin la preocupación por la compatibilidad del navegador.
-
-Después de empaquetar pero antes de que el código empaquetado se escriba en el archivo, el código se pasa por `pretty-fast`. Si no está destinado a ser minificado, debería ser limpiado para que el formato final sea un poco más consistente (anticipamos que el código fuente de p5.js se pueda leer e inspeccionar si se desea).
+Este comando verifica los archivos fuente, los scripts de compilación (build scripts), los archivos de prueba y los ejemplos de documentación usando ESLint.
 
-Aquí se omiten algunos pasos detallados pequeños; puedes revisar el archivo de definición de construcción de browserify vinculado arriba para ver todo más de cerca. 
+Si solo quieres ejecutar la verificación de estilo (linting) para archivos o directorios específicos, puedes usar ESLint directamente:
 
 ```
-connect:server
+npx eslint src/
+npx eslint test/
 ```
 
-Este paso inicia un servidor local que aloja los archivos de prueba y los archivos de código fuente construidos para que las pruebas automatizadas puedan ejecutarse en Chrome.
+Ya no existe un linter separado para ejemplos ni un pipeline basado en YUIDoc.
 
-```
-mochaChrome
-```
-
-Este paso está definido en [./tasks/test/mocha-chrome.js](tasks/test/mocha-chrome.js). Utiliza Puppeteer para iniciar una versión sin interfaz de usuario de Chrome que puede ser controlada de forma remota y ejecuta las pruebas asociadas con los archivos HTML en la carpeta `./test`, que incluye la prueba de la versión sin minificar y minificada de la biblioteca contra los conjuntos de pruebas unitarias, así como la prueba de todos los ejemplos de referencia.
-
-
-```
-mochaTest
-```
+#### Tarea `test`
 
-Este paso difiere de `mochaChrome` en que se ejecuta en node.js en lugar de en Chrome y solo prueba un pequeño subconjunto de características en la biblioteca. La mayoría de las características en p5.js requerirán un entorno de navegador, por lo que este conjunto de pruebas solo debe ampliarse si las nuevas pruebas realmente no necesitan un entorno de navegador.
+En p5.js 2.0, el sistema de pruebas ya no usa Mocha mediante Grunt. En su lugar, las pruebas se ejecutan usando [Vitest](https://vitest.dev/) a través de scripts de npm.
 
+Para ejecutar el conjunto completo de pruebas (unit y visual tests), usa:
 
 ```
-nyc:report
+npm test
 ```
 
-Finalmente, después de que todas las construcciones y pruebas estén completas, este paso recopilará el informe de cobertura de pruebas mientras `mochaChrome` estaba probando la versión completa de la biblioteca y mostrará los datos de cobertura de pruebas en la consola. La cobertura de pruebas para p5.js es principalmente para monitorear y tener algunos puntos de datos adicionales; tener una cobertura de pruebas del 100% no es un objetivo.
-
-¡Y eso cubre la tarea predeterminada en la configuración de Gruntfile.js!
+Este comando realiza:
 
+- Verificación de estilo (linting) mediante ESLint
+- Pruebas unitarias (unit tests) usando Vitest
+- Pruebas visuales (capturas de renderizado)
 
-### Tarea Variada
+Las pruebas se encuentran en la carpeta `test/unit`, organizadas de manera que reflejen la estructura del directorio `src`. Por ejemplo, las pruebas para `src/color/p5.Color.js` están en `test/unit/color/p5.Color.js`.
 
-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.
+Para ejecutar las pruebas interactivamente en un entorno similar al navegador (útil para identificar errores o debuggear), ejecuta:
 
 ```
-grunt yui:dev
+npx vitest --ui
 ```
-
-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.
-
-`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.
+También se puede generar la cobertura de código usando las herramientas integradas de Vitest. Ejecuta:
 
 ```
-grunt watch
-grunt watch:main
-grunt watch:quick
+npx vitest run --coverage
 ```
 
-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.
-
-La tarea `watch` ejecutará todas las construcciones y pruebas de manera similar a ejecutar la tarea predeterminada completa al detectar cambios en el código fuente.
-
-La tarea `watch:main` ejecutará la construcción y las pruebas de la biblioteca, pero no reconstruirá la referencia al detectar cambios en el código fuente.
-
-La tarea `watch:quick` ejecutará solo la construcción de la biblioteca al detectar cambios en el código fuente.
-
-Dependiendo de en qué estés trabajando, elegir la tarea de observación más mínima aquí puede ahorrarte tener que ejecutar manualmente una reconstrucción cada vez que desees hacer algunos cambios.
-
----
+Nota: El proceso de compilación de Browserify/Grunt (por ejemplo, `browserify`, `uglify`, `brfs-babel`) fue eliminado en la versión 2.
 
 
 ## Proceso de Lanzamiento