¡Este es el cliente web de código abierto de Scratch! Este es el código de gran parte del sitio web de Scratch.
En particular, esta base de código incluye código para:
El proyecto scratch-www tiene muchos aspectos de su diseño que son particulares de nuestros sistemas backend. Para usarlo para su propio proyecto, tendría que mirar todos los lugares donde realiza llamadas de backend y crear sus propios sistemas de backend para realizar esas funciones.
El proyecto scratch-gui, por otro lado, está diseñado para que cualquier persona pueda utilizarlo, sin necesidad de crear sistemas backend, aunque también puede admitir sistemas backend para guardar proyectos y activos.
¡Agradecemos sus contribuciones a este código base! Es posible que desee comenzar explorando la lista actual de problemas abiertos con la etiqueta "se busca ayuda".
Contribuir a scratch-www puede ser más difícil que contribuir a scratch-gui. Esto se debe a que scratch-gui se puede ejecutar por sí solo, sin necesidad de que se ejecute ningún otro servicio, mientras que scratch-www necesita comunicarse con varios sistemas backend que ejecuta el equipo de Scratch (consulte "Cómo encaja esto con otros repositorios de Scratch"). arriba). Si es nuevo contribuyendo al código fuente de Scratch, le sugerimos que comience familiarizándose con scratch-gui y su lista de problemas abiertos etiquetados como "se busca ayuda".
Para contribuir, siga los pasos estándar para contribuir a un proyecto en GitHub.
Consulte el archivo de LICENCIA en este repositorio.
Aquí hay algunos recursos que lo ayudarán a familiarizarse con cómo trabajamos en el código base de Scratch:
Las tecnologías centrales importantes que utiliza esta base de código incluyen:
Nuestras pruebas utilizan:
Asegúrate de haber instalado:
Es importante asegurarse de que todas las dependencias estén actualizadas porque el código scratch-www solo funciona con versiones específicas de las dependencias. Puede actualizar los paquetes usando el comando:
npm install
Estas advertencias se pueden ignorar con seguridad:
npm WARN [email protected] requires a peer of react@^0.14.0 but none was installed.
npm WARN [email protected] requires a peer of react@^0.14.0 but none was installed.
npm WARN [email protected] requires a peer of redux@^2.0.0 || ^3.0.0 but none was installed.
npm WARN [email protected] requires a peer of react@^0.14.7 but none was installed.
npm WARN [email protected] requires a peer of react@^0.14.8 but none was installed.
Estos existen actualmente en static/js/lib.
Para compilar el código fuente en paquetes HTML y JavaScript que los navegadores puedan leer, puede crear una versión temporal del sitio en su máquina a la que pueda acceder a través de su navegador web.
Puede "construir" el sitio una sola vez ejecutando:
npm run build
O puede ejecutar un servidor que reconstruya los archivos a medida que los edita, ejecutando los comandos:
npm run translate
npm start
NOTA: npm run translate
crea el directorio intl. El sitio se construirá bien sin él, pero las cadenas de texto traducibles no se mostrarán correctamente hasta que haya creado intl.
Durante el desarrollo, npm start
observa cualquier actualización que realice en los archivos en ./static
o ./src
y activa una reconstrucción del proyecto. En desarrollo, la compilación se almacena en la memoria y no se sirve desde el directorio ./build
.
Una vez que haya creado el sitio local, utilizando npm run build
o npm start
, un navegador web podrá acceder al sitio alojado en su máquina local ingresando localhost:8333
en la barra de direcciones de su navegador.
Al ejecutar npm start
, aquí hay algunos mensajes de registro importantes a los que debe estar atento:
webpack: bundle is now VALID.
– El paquete se ha cargado en la memoria y ahora se puede ver en el navegador. Esto aparecerá una vez que npm start
haya completado su configuración y también una vez que las actualizaciones que realice en los archivos se hayan vuelto a compilar para verlas en el navegador.webpack: bundle is now INVALID.
– Si ve esto, significa que ha realizado actualizaciones en los archivos que aún se están compilando para su visualización en el navegador. Las páginas seguirán siendo visibles, pero no verán ninguna actualización que hayas realizado todavía. Para detener el proceso npm start
que hace que el sitio esté disponible para su navegador web (creado arriba en "Para construir"), use ^C
(control-c) en la terminal.
npm start
se puede configurar con las siguientes variables de entorno, configurándolas al principio del comando, antes de npm start
:
Variable | Por defecto | Descripción |
---|---|---|
API_HOST | https://api.scratch.mit.edu | Nombre de host para solicitudes de API |
ASSET_HOST | https://assets.scratch.mit.edu | Nombre de host para solicitudes de activos |
BACKPACK_HOST | https://backpack.scratch.mit.edu | Nombre de host para solicitudes de mochila |
PROJECT_HOST | https://projects.scratch.mit.edu | Nombre de host para solicitudes de proyectos |
FALLBACK | '' | Ubicación de paso para el sitio antiguo |
THUMBNAIL_URI | /internalapi/project/thumbnail/{}/set/ | Plantilla de URI para actualizar las miniaturas del proyecto; {} se reemplaza por el ID del proyecto al invocar una solicitud |
THUMBNAIL_HOST | '' | Nombre de host para el servicio de carga |
GTM_ID | '' | ID del Administrador de etiquetas de Google |
GTM_ENV_AUTH | '' | Información de autenticación y entorno de Google Tag Manager |
NODE_ENV | null | Si no es production , la aplicación actúa como desarrollo. |
PORT | 8333 | Puerto para devserver (http://localhost:XXXX) |
NOTA: Debido a que de forma predeterminada API_HOST=https://api.scratch.mit.edu
, tenga en cuenta que, de forma predeterminada, verá e interactuará con datos reales en el sitio web de Scratch.
La mayoría de nuestras pruebas unitarias se ejecutan con Jest, pero las pruebas unitarias más antiguas utilizan el marco TAP.
Para compilar la aplicación y ejecutar todas las pruebas unitarias y de localización, utilice el comando:
npm test
Para ejecutar un archivo de prueba de una sola unidad desde la línea de comandos usando Jest, use el comando:
node_modules/.bin/jest ./test/unit/PATH/TO/FILENAME.test.js
NOTA: reemplace PATH/TO/FILENAME
con la ruta real al archivo que desea ejecutar.
Nuestras pruebas de integración suponen que se está ejecutando un entorno más amplio que el de scratch-www por sí solo; por ejemplo, muchos requieren que un usuario de prueba pueda iniciar sesión en el sitio, lo que requiere soporte de base de datos y backend.
De forma predeterminada, las pruebas se ejecutan en nuestra instancia de Staging, pero puede pasar una ubicación diferente con la variable de entorno ROOT_URL (ver a continuación) si desea ejecutar las pruebas en otra ubicación, por ejemplo, su compilación local.
Todas nuestras pruebas de integración utilizan Jest como nuestro marco de prueba.
Para ejecutar todas las pruebas de integración desde la línea de comandos:
SMOKE_USERNAME=username SMOKE_PASSWORD=password ROOT_URL=https://scratch.mit.edu UNOWNED_SHARED_PROJECT_ID= # UNOWNED_UNSHARED_PROJECT_ID=# OWNED_SHARED_PROJECT_ID=# OWNED_UNSHARED_PROJECT_ID=# npm run test:integration
Las pruebas utilizan varios usuarios con nombres de usuario similares y la misma contraseña. Usan el nombre de usuario que ingresas con SMOKE_USERNAME, así como el mismo nombre de usuario con un 1, 2, 3, 4, 5 y 6 (que pronto serán números más altos también) agregado al final. Entonces, si usa el nombre de usuario "prueba", también usará el nombre de usuario "prueba1", "prueba2", "prueba3", etc. Asegúrese de haber creado cuentas con este patrón y use la misma contraseña para todas las cuentas involucradas.
Puede utilizar cualquier conjunto de nombres de usuario que se ajusten a este patrón. Cada cuenta debe compartir la misma contraseña, que se pasa como SMOKE_PASSWORD.
Es necesario pasar varias variables de entorno para que se ejecuten las pruebas. La mayoría de ellos tienen valores predeterminados que apuntan al servidor provisional.
Para ejecutar un solo archivo desde la línea de comandos usando Jest:
SMOKE_USERNAME=username SMOKE_PASSWORD=password ROOT_URL=https://scratch.mit.edu node_modules/.bin/jest ./test/integration/filename.test.js
Para ejecutar un solo archivo desde la línea de comandos usando TAP:
SMOKE_USERNAME=username SMOKE_PASSWORD=password ROOT_URL=https://scratch.mit.edu node_modules/.bin/tap ./test/integration-legacy/smoke-testing/filename.js -R classic --no-coverage --timeout=3600
-R classic
hace que tap use el estilo de informes antiguo, lo que evita un error con el paquete "nyc"--no-coverage
se debe a que no utilizamos la función de seguimiento de cobertura de taptimeout
es para toda la duración de todo el conjunto de pruebas de tap; Si recibe un error de tiempo de espera, es posible que deba ajustar este valor (algunas de las pruebas de Selenium tardan un poco en ejecutarse) Las pruebas de integración se pueden ejecutar utilizando Saucelabs, un servicio en línea que puede probar múltiples combinaciones de navegador/sistema operativo de forma remota. (Actualmente, todas las pruebas están escritas para su uso en Chrome en Mac).
Necesitará una cuenta de Saucelabs para poder utilizarla para realizar pruebas. Si tiene una, puede encontrar su clave de acceso:
Para ejecutar pruebas usando Saucelabs, ejecute el comando:
SMOKE_USERNAME=username SMOKE_PASSWORD=password SAUCE_USERNAME=saucelabsUsername SAUCE_ACCESS_KEY=saucelabsAccessKey ROOT_URL=https://scratch.mit.edu npm run test:integration:remote
NOTA: Actualmente, las pruebas de Jest no se ejecutarán con Saucelabs.
Variable | Por defecto | Descripción |
---|---|---|
ROOT_URL | scratch.ly | Ubicación en la que desea ejecutar las pruebas |
SMOKE_USERNAME | None | Nombre de usuario del usuario de Scratch con el que inicia sesión para realizar la prueba |
SMOKE_PASSWORD | None | Contraseña del usuario de Scratch con el que estás iniciando sesión para realizar la prueba |
SMOKE_REMOTE | false | Pruebas con Sauce Labs o no. Verdadero si se ejecuta prueba: humo: salsa |
SMOKE_HEADLESS | false | Ejecute el navegador en modo sin cabeza. Flaco por el momento |
SAUCE_USERNAME | None | Nombre de usuario para su cuenta de Sauce Labs |
SAUCE_ACCESS_KEY | None | La clave de acceso para Sauce Labs se encuentra en Configuración de usuario |
La implementación en pruebas o producción cargará el código en S3 y configurará Fastly.
npm install
virtualenv ENV
. ENV/bin/activate
pip install -r requirements.txt
npm run build && npm run deploy
Variable | Por defecto | Descripción |
---|---|---|
FASTLY_SERVICE_ID | '' | ID de servicio Fastly para bin/configure-fastly.js |
FASTLY_API_KEY | '' | Clave API de Fastly para bin/configure-fastly.js |
FASTLY_ACTIVATE_CHANGES | false | Activar cambios y purgar todo después de configurar |
AWS_ACCESS_KEY_ID | '' | ID de clave de acceso de AWS para S3 |
AWS_SECRET_ACCESS_KEY | '' | Clave de acceso secreta de AWS para S3 |
S3_BUCKET_NAME | '' | Nombre del depósito de S3 en el que implementar |
Durante la implementación, la API de Fastly se utiliza para clonar la configuración VCL activa, actualizar solo el componente relevante con el contenido del archivo routes.json
de este repositorio y activar la nueva configuración VCL.
Gran parte del archivo route.json es sencillo, pero el propósito de algunos campos no es obvio.
routeAlias
nos ayuda a evitar que la longitud total y la complejidad del código de comparación de expresiones regulares en Fastly sean demasiado grandes. Hay una expresión regular grande con la que Fastly prueba la URL de solicitud entrante para saber si puede responder con un archivo estático en S3; Si no se encuentra ninguna coincidencia, asumimos que debemos pasar la solicitud a scratchr2. Podríamos probar cada expresión regular pattern
de ruta en routes.json
, pero muchas son similares, por lo que simplemente tomamos el conjunto único de todas las entradas routeAlias
, que es más corto y rápido.
Para el desarrollo en Windows, probablemente necesitará utilizar un programa que le proporcione una interfaz Unix.
Hay varias opciones para hacer esto:
Además, necesitarás instalar Node; Aquí hay instrucciones para instalar Node en WSL.
Actualmente estamos en el proceso de transición a este cliente web desde la estructura existente de Scratch. A medida que hagamos la transición, habrá algunos problemas relacionados con cómo este cliente necesita interactuar con la infraestructura existente para funcionar correctamente en producción.
Además de migrar para usar esto como nuestro cliente web, Scratch también está haciendo la transición para usar una nueva API backend, Scratch REST API (código cerrado). Como esto también está actualmente en desarrollo e incompleto, estamos configurados para recurrir al uso de puntos finales de Scratch existentes si no existe un punto final API, que es donde entra en juego el FALLBACK
.
La mayoría de los problemas que tenemos actualmente giran en torno al uso de FALLBACK
. Esta variable se utiliza para especificar a qué URL recurrir en caso de que falle una solicitud dentro del contexto de este cliente web o cuando se utiliza API_HOST
. Si no se especifica en el proceso, no se utilizará y cualquier solicitud que no se realice a través del cliente web o la API será inalcanzable.
Configurar FALLBACK=https://scratch.mit.edu
permite que el cliente web recupere datos del sitio web de Scratch en su entorno de desarrollo. Sin embargo, por motivos de seguridad, intentar enviar datos a Scratch a través de su entorno de desarrollo no funcionará. Esto significa que las siguientes cosas estarán rotas por el momento:
Además, si configura FALLBACK=https://scratch.mit.edu
, tenga en cuenta que al hacer clic en enlaces a partes del sitio web que aún no se han migrado (actualmente, como Discuss
, Profile
, My Stuff
, etc.) lo llevará a el propio sitio web de Scratch.