Open fabianabarca opened 3 years ago
Esta es una de las herramientas junto con las otras que ya ustedes conocen
Estamos teniendo un problema y es que antes de remover los estáticos es necesarico comenzar a usar las dependencias propias del proyecto por medio del manejador de paquetes JavaScript, es por esto que hice commits revert al branch de tree-shaking la idea es que antes de borrar cosas de /static que deberían estar en el tema lo mejor es mantener el package.json lo más cercano a stable para comenzar a trabajar dependencias desde esta rama ya que están evolucionando por aparte y esto tampoco es sano. Los reverts solo anulan los commits de borrar estáticos, el branch de tree-shaking es equivalente a que solo se hubiera agregado el package.json y las dep de vue, webpack, pero con la diferencia que la historia permanece entonces en caso de necesitar esos commits destructivos se puede regresar en el tiempo y usarlos.
Lo primero que habría que hacer antes de sacar todo el lastre estático y usar el tema correctamente sería automatizar el minificado y el pull de dependencias del código propio del proyecto, es decir, aquel JS que solo habita en este repositorio y no es thirdparty
[ ] Estabilizar la rama y los ficheros asociados a NPM dependencias y scripts, lo suficiente como para sentarla en stable y construir los JS partiendo ya de esta configuración de webpack para los scripts del proyecto.
[ ] Hacer un rebase a treeshaking de las ramas enfocadas en frontend para agregarlas ya al esquema de webpack
[ ] Sacar todo el JS de rutas o django-apps específicas del static/ global y ponerlos en el respectivo static/ de cada directorio, realizar los cambios pertinentes en templates etc.
Respecto a este tercer punto lo que pasa es que cada fichero estático que solo se usa en X página debería mantenerse en el directorio django-app/static/ por orden, a la hora de hacer el deployment de la versión de producción ahí sí se toman todos los static/
Static de rutas lleva adentro otro directorio llamado rutas porque a la hora de moverlo al static global entonces en la URL quedará ese rutas que identificará a los estáticos de esta Django-app con respecto a los de todos los demás, por eso parece redundante pero no lo es, lo que pasa es que está pensado para cuando ya todos estén juntos en el NGINX no se mezclen y no haya colisiones de cosas que se llamen igual.
rutas/
├── admin.py
├── apps.py
├── fixtures
│ ├── agency.json
│ ├── calendar_dates.json
│ ├── calendar.json
│ ├── fare_attributes.json
│ ├── fare_rules.json
│ ├── feed_info.json
│ ├── routes.json
│ ├── stop.json
│ ├── stops.json
│ ├── stoptime.json
│ ├── stop_times.json
│ ├── trip.json
│ ├── trips.json
│ └── zones.json
├── migrations
│ ├── 0001_initial.py
│ ├── __init__.py
├── models.py
├── static
│ └── rutas
│ └── terminal.png
├── templates
│ ├── proximobus.html
│ ├── ruta.html
│ ├── rutas.html
│ ├── tabla-tarifas.html
│ └── tarifas-cards.html
├── tests.py
├── urls.py
└── views.py
Algo así como https://web.dev/ para analizar cómo mejorar el sitio.