Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Centralize libs base path and unify library loading across frontend

Aperta
  • Qualcosa non va?
#1,857 0 commenti 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@erseco ci sta già lavorando.

Dal 22/6/2026.

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

enhancement low priority

Background

Several places in the frontend independently resolve the path to vendored libraries under public/libs/ and load scripts in slightly different ways. This is a small but real source of duplication, and it makes it harder to land cross-cutting work like #1593 (which is removing committed vendor artifacts and rebuilding them from Bun dependencies).

This issue tracks the cleanup so that both concerns — where public/libs/ lives at runtime and how a module pulls a script from it — share a single, reusable surface.

Motivation

This came out of the slide iDevice hotfix #1850, where @ignacigros pointed out that the bridge's loadScript and resolveLibsBase helpers look like things that probably belong in a shared place. Two related complaints in the same area:

  • public/preview-sw.js hardcodes /libs/pdfjs/pdf.min.mjs and /libs/pdfjs/pdf.worker.min.mjs.
  • public/files/perm/idevices/base/slide/edition/slide.js derives /libs/ from its own iDevice path via a local resolveLibsBase() helper (slide.js:64).
  • eXe.app.loadScript in public/app/workarea/project/idevices/idevicesEngine.js:2772 exists but is workarea-only, callback-style, and unconditionally appends ?t=${Date.now()} cache-busting — making it unsuitable as-is for large vendored libs (Fabric ~330 KB, DOMPurify ~22 KB) that we want the browser to cache across iDevice opens.

PR #1593 ("Removed bundled libraries and generate from package.json dependencies") is directly complementary: it changes how vendored files arrive into public/libs/ at build time. Centralizing how runtime code consumes them removes friction for that effort, and avoids new ad-hoc path resolvers landing in parallel.

Proposed scope

  1. Centralize the libs base URL. Expose something like eXe.app.paths.libs (or window.eXeLearning.paths.libs), seeded once from the same place that knows BASE_PATH. Replace the local resolvers in:

    • public/preview-sw.js
    • public/files/perm/idevices/base/slide/edition/slide.js (resolveLibsBase)
    • any other call site found during the work.

  2. Provide a Promise-based, cache-friendly loadScript (or rework eXe.app.loadScript) that:

    • returns a Promise (so callers can chain dependencies cleanly),
    • does not cache-bust by default — opt-in via a flag, so vendored singletons (fabric, dompurify, …) benefit from the browser cache across opens,
    • keeps the existing tag-tracking / cleanup behavior for one-shot scripts,
    • degrades gracefully when eXe.app is not available (e.g. iDevice running in the static editor / embedding host / unit tests).

  3. Migrate existing call sites (slide iDevice bridge first) once both pieces are in place.

Out of scope

  • Refactoring eXe.app.loadScript consumers outside iDevices in this issue.
  • Changing the runtime asset layout — that's #1593's territory.

References

  • PR #1850 — slide iDevice hotfix that surfaced the suggestion.
  • PR #1593 — removes committed vendor artifacts and generates them from Bun dependencies; complementary to this work.
  • public/app/workarea/project/idevices/idevicesEngine.js:2772 — current loadScript.
  • public/files/perm/idevices/base/slide/edition/slide.js:64 — current resolveLibsBase.
  • public/preview-sw.js — hardcoded /libs/pdfjs/... paths.
Lingua principale
JavaScript
Stelle
145
Fork
33
Merge medio
3g 14h
PR unite (30g)
93

Preparare l'ambiente

  • Include un Dockerfile o un file Docker Compose
  • Nessun modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di exelearning/exelearning

Tutte le issue di exelearning/exelearning

Issue simili

Altre issue su JavaScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.