Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Restructure: deploy a site/ directory instead of a hand-maintained allowlist, and cap source images at 4K

Abierto
  • ¿Algo no está bien?
#102 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
42/100
Tipo de issue
Refactorización
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
github-actions, html, javascript, sass
Área
build-system, ci-cd, web-dev

Línea de trabajo

Empieza con #101 y luego inspecciona .github/workflows/static.yml y links.yml, .mega-linter.yml, .stylelintignore, .pre-commit-config.yaml, package.json y scripts/optimize-images.mjs. Ejecuta los comandos existentes de CSS y validación para establecer el artefacto actual y, después, verifica el nuevo diseño de site/, las ubicaciones de las imágenes, los globs de enlaces y el límite de 3840px para el lado más largo conforme a los criterios de aceptación indicados.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

infra

Follow-up to #99 / #100, which fixed one symptom: llms.txt was linted and
link-checked on every PR but never deployed, because static.yml assembles
_site/ from a hand-written list of filenames and nobody remembered to extend it.

That list is the actual defect. It is easy to add a file next to and forget.

Part 1 — move deployable content into site/

Why not a denylist at the repo root

Worth stating, because it is the obvious idea and it is the one option that
cannot work here. The root is shared: main's Astro rebuild builds dist/,
.astro/ and node_modules/ in this same working directory, and .venv/,
.claude/ worktrees, megalinter-reports/ and lighthouse-reports/ all land at
root too. "Copy everything except X" from root means the next ignored directory
someone adds leaks into production. The allowlist exists for that reason and the
reason is sound.

Why site/ fixes it properly

It turns the boundary from a list of filenames into a directory:

cp -r site/. _site/

Exhaustive by construction. Tooling cannot leak because it lives outside site/.
A new page is deployed and link-checked with no list to remember, once
links.yml globs site/**/*.html.

_site/ still exists as a staging copy — scripts/optimize-images.mjs rewrites
images in place and must not touch the repo's masters. The goal is not to remove
the staging step, only to make the copy exhaustive rather than enumerated.

Naming

site/, not src/. There is no compile step, and main uses Astro's
src//public/ conventions in this same working directory — worth not
overloading the word.

What has to move out of the deployable tree

Two image directories are in the repo deliberately and deliberately never served;
static.yml currently rm -rfs them from _site/ after copying. If images/
moves wholesale into site/ they come along and the denylist is back, just
smaller. Move them to originals/ at root instead:

  • images/will/JPEGs/ — 3.6 MB of masters; only JPEGs_FBK/ is referenced (one headshot, 2026_Headshot_1x1.jpg)
  • images/gallery/photographer/product/ — 13 MB, unreferenced by any page

Both confirmed unreferenced by grep across all HTML, CSS, JS, XML and txt. After
this, "in the repo but not served" stops being a rule inside a workflow and
becomes a fact about where the file lives.

assets/sass/ is source, not served, so it moves out too — with npm run css
writing to site/assets/css/main.css.

Not breaking the image links

The thing to get right. Pages and images/ move together, so every relative
path in the HTML (images/foo.jpg) is unchanged — site/index.html referencing
images/foo.jpg resolves to site/images/foo.jpg locally, and to /images/foo.jpg
once site/ is copied to the artifact root. Local preview and deploy both keep
working without editing a single src attribute.

Only the two unreferenced directories above change location, which is exactly why
it matters that they are unreferenced.

Config to update

Mechanical, but it is the bulk of the work:

  • .github/workflows/static.yml — the copy step
  • .github/workflows/links.yml — lychee globs, both passes
  • .mega-linter.yml — FILTER_REGEX_EXCLUDE
  • .stylelintignore
  • .pre-commit-config.yaml — the standard excludes and build-css files: regex
  • package.json — the css and css:check scripts

LICENSE.txt, CLAUDE.md, package.json and the dotfiles stay at root.

Part 2 — cap source images at 4K

190.4 MB of tracked images; .git is 148 MB. 21 MP masters are not worth
carrying when the largest realistic viewport is 4K, and the deploy-time optimizer
caps at 2000px for gallery fulls anyway — so the committed pixels above that are
never served to anyone.

25 files have a long edge over 3840px, totalling 94.9 MB. Gallery fulls are
5184x3456.

One decision to make: 2160p is a height, and a cap has to handle both
orientations. Suggest capping the long edge at 3840 regardless of orientation
— simple, and portrait images end up 2560x3840 which is still more than a 4K
display can show. Capping the short edge instead would leave panoramas enormous.

Note this is mostly about repo weight, not site performance — optimize-images.mjs
already handles what gets served.

Sequencing

  1. #100 — llms.txt, landed separately
  2. #101 first. 71.5 MB of the 190 MB is trailing garbage after the JPEG EOI marker, recoverable losslessly. Do that before any resize work so the resize is applied to sane files and the diff is readable.
  3. originals/ split + site/ move — two commits, one PR, so a reviewer can see the file list is otherwise identical
  4. 4K cap as its own PR, since it is the only part involving quality judgement

Acceptance criteria

  • _site/ built the new way is byte-identical to the old way, apart from llms.txt
  • Deploy step contains no per-file list
  • Every image renders, checked on every page, both locally and on a deploy preview
  • Nothing outside site/ reaches the artifact — assert the deployed file set equals git ls-files site/
  • No committed image exceeds 3840px on its long edge
  • links.yml picks up a newly added page with no workflow edit

Related: #31 (v2 image pipeline on main — same underlying problem, different
branch and a different fix; this issue is v1 on master, and the two are
complementary rather than duplicates).

Lenguaje dominante
HTML
Estrellas
0
Forks
0
Merge medio
9 h 52 min
PR fusionados (30 d)
59

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

  • Sin Dockerfile ni archivo de Docker Compose
  • Sin plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de laywill/laywill.github.io

Todos los issues de laywill/laywill.github.io

Issues similares

Más issues de Build System

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.