Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Release process: add a built-artifact (dist/bundle) check to catch runtime regressions before publish

Ouverte
#765 2 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
48/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Calme
Stack technique
firebase, node.js, react, typescript

Piste de recherche

Commencez par les vérifications proposées sur la sortie de npm pack, en particulier dist/index.js, les chemins exports/main/module du package et les commandes d’import Node ESM et CommonJS. Définissez une gate avant publication couvrant require dynamique et les vérifications externes, le chargement du point d’entrée, l’intégrité des chemins du tarball et la comparaison de la taille du bundle ; les applications de smoke test à l’exécution et le diff de .d.ts sont des suivis connexes. C’est terminé lorsque le processus de release détecte les régressions décrites dans #759 avant la publication.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Motivation

#759 (the App Router / Vite client crash in 4.2.4 and 4.2.5) shipped because the build-tooling migration silently changed the built ESM output: use-sync-external-store/shim (CJS) started getting bundled into the ESM dist, producing a dynamic require() that throws in any browser bundle (Calling \require` for "react" in an environment that doesn't expose the require function`). The source was unchanged; only the emitted artifact regressed, and nothing in the release flow compared the artifact before publish.

This is the second dist-level regression to ship as a patch: #749 already proposes a published .d.ts diff to catch the type side (the 4.2.4 ObservableStatus break). This issue covers the runtime/bundle side. Together they form a built-artifact diff gate.

Proposed pre-publish checks

A concrete checklist for a pre-publish gate (each item derived from auditing the 4.2.6 release by hand). Items marked would have caught #759.

  1. No dynamic require( / CJS-interop shims in the ESM dist. Grep dist/index.js for \brequire\b, __require, createRequire, __commonJS. (Would have caught #759: require count went 0 at 4.2.3 to 3 at 4.2.4+.)
  2. Externals are not inlined. Only rxfire / rxjs / tslib should be bundled; react, firebase/*, @firebase/*, and use-sync-external-store/shim must stay external import specifiers. Catches accidental bundling that causes duplicate-instance bugs.
  3. Both entry points load. node --input-type=module -e "import('reactfire')" and node -e "require('reactfire')" (in a fixture with react + firebase installed) must resolve without throwing. Catches missing/renamed files and broken imports.
  4. exports map integrity. Every path referenced by exports / main / module exists in the packed tarball.
  5. Bundle-size delta vs previous latest. npm pack the current latest, compare dist size; flag large jumps (a proxy for accidental inlining).
  6. Published .d.ts diff vs previous version. Type-side counterpart, tracked in #749; catches the 4.2.4 ObservableStatus break class.
  7. Runtime smoke render in CI (strongest). A minimal Next App Router (turbopack) and Vite app that renders a data hook against the packed build; fails on the #759 crash. This is the check that catches runtime regressions the static greps miss.

Items 1 to 5 are cheap and scriptable against npm pack output; 7 is the higher-value integration check.

Related
  • #749 (published .d.ts diff, the type-side counterpart)
  • #759 / #760 (the regression this would have caught, and its fix)
Langage dominant
TypeScript
Étoiles
3.6k
Forks
403
Merge moyen
5 j 1 h
PR mergées (30 j)
10

Guide de contribution

Ouvrir le guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de FirebaseExtended/reactfire

Toutes les issues de FirebaseExtended/reactfire

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.