pnpm a Parcel based monorepo

Problém

V minulosti jsem vyzkoušel několik způsobů správy JavaScript/TypeScript Library Monorepos:lerna , yarn workspaces , atd.

Nechápejte mě špatně:Jsou to skvělé nástroje a velmi oceňuji úsilí, které do nich jejich autoři vložili.

Vždycky se ale cítili tak trochu jako hazard. Nikdy jsem neměl pocit, že bych měl skutečně kontrolu nad tím, co se děje (se spoustou černé magie), a zjistil jsem, že se cítí trochu... křehké (vždy jsem se obával, že poruším nějaké symbolické odkazy nebo podobné věci, když spustím nějaké příkazy).

Řešení?

Chtěl jsem vyzkoušet oba pnpm a Parcel. Slyšel jsem o obou nástrojích dobré věci a v poslední době jsem stále více frustrovaný jejich zavedenějšími konkurenty.

Když jsem se podíval na jejich příslušné stránky s dokumentací, vypadalo to, že obě mají skvělou monorepo podporu. Protože jsem také stále dlouho hledal nějaké monorepo řešení kompatibilní s "sestavením knihovny npm" s lepšími vývojářskými zkušenostmi, než jaké jsem dosud viděl, rozhodl jsem se to zkusit.

Úložiště

Takže jsem vytvořil (a zdokumentoval) testovací úložiště, abych vyzkoušel toto nové nastavení monorepo:

pnpm &parcel monorepo test

Úložiště pro vyzkoušení nastavení monorepo knihovny JS/TS npm pomocí pnpm jako správce balíčků a parcel jako nástroj pro vytváření.

Předpoklady pro vývoj:

  • Uzel v16+
  • pnpm

Technický zásobník

Toto je přehled nejdůležitějších součástí technologického zásobníku tohoto monorepa

  • pnpm -- správce pracovního prostoru balíčků a monorepo
  • Balík -- nástroj pro vytváření
  • Jest / ts-jest -- Rámec testování jednotek
  • TypeScript / tsc -- Kontrola typu TypeScript
  • TypeScript ESLint -- lincování
  • Hezčí -- formátovač kódu
  • fliegdoc -- generátor dokumentace
  • Akce GitHubu -- Potrubí CI
  • Renovovat -- Správa aktualizací závislostí

Využití

Nastavení vývojového prostředí

Instalace závislostí:

pnpm install
  • automaticky rekurzivně běží pro pracovní prostor, srov. https://pnpm.io/cli/install
  • Alias:pnpm i
  • npm ci -ekvivalent:pnpm i --frozen-lockfile (automaticky true v prostředí CI)

Můžete také spustit pnpm install když se cokoli o vašich závislostech stane zastaralým, abyste to mohli opravit.

Správa závislostí

Instalace

… Zobrazit na GitHubu

Úložiště obsahuje testovací nastavení s víceméně plným technologickým zásobníkem, který se mimo jiné skládá z:

  • TypeScript
  • ESLint
  • Hezčí
  • fliegdoc (vlastně vytvořený generátor dokumentace)
  • jest / ts-jest
  • Akce GitHubu

Většinu věcí jsem popsal v README.md , ale také jsem vytvořil další veřejnou stránku Pojem popisující další podrobnosti.

Výsledky

Jsem opravdu spokojený s tím, jak to funguje, a určitě tento přístup využiji i v budoucnu. V budoucnu také pravděpodobně převedu stávající monorepo na tento přístup.

Výhody

  • 🟢 máte pocit, že to máte pod kontrolou s pnpm , je docela jednoduché porozumět tomu, jak jejich systém pracovního prostoru funguje, takže máte pocit, že to máte pod kontrolou a nemusíte hádat o řešení svých problémů 🎉. Např. pnpm install vše nastaví. Dříve jsem si vždy nebyl jistý, zda mám nyní spustit npm install , lerna bootstrap , nebo něco jiného.
  • 🟢 rychlé doby sestavení od parcel sestaví všechny balíčky najednou (místo spouštění sestavení skriptů po jednom balíčku), časy sestavení (zejména s mezipamětí sestavení) jsou neuvěřitelně rychlé
  • 🟢 zkušenosti s vývojem s parcel watch , je možné velmi rychle vyvinout
  • 🢢 "nativní" pracovní prostory práce s pracovními prostory / více balíčky se zdá být "nativní" pro pnpm (oproti jeho konkurentům, kde jsem bohužel zjistil, že mi to přijde spíše jako "hacky side feature"). Příkazy fungují tak, jak bych očekával, že budou fungovat, "interní" závislosti mezi balíčky jsou automaticky doplněny čísly verzí při publikování a tak dále.

Nevýhody

Každý přístup má samozřejmě několik nevýhod. Zde jsou ty, které jsem zatím našel:

  • 🟡 menší podpora ekosystému zatímco pnpm a parcel fungují skvěle v 99 % případů, nástroje pro ně často netestují podporu tak, jako například pro yarn a webpack
  • 🟢 (žádná podpora Dependabot) v době psaní tohoto článku Dependabot na GitHubu nepodporuje pnpm . Naštěstí se zdá, že Renovate funguje dobře.
  • 🟢 (žádné nástroje „automatizace uvolnění“) lerna přišel se skvělými nástroji pro automatizaci vydání založených na Changelogu / Konvenčním Commit / .... Bohužel jsem zatím nenašel skvělé řešení, jak udělat něco podobného s pnpm . Máte nějaká doporučení?

Rychlá oprava chyby balíku, kvůli které jsem ji málem zavrhl

Když jsem zpočátku testoval Parcel, připadal mi nestabilní. Nešlo by to vypnout, čas od času by prostě přepsal můj package.json a celkově nefungují vůbec dobře.

Byl jsem téměř připraven vzdát se, když jsem našel tento problém na GitHubu. Ukázalo se, že jsem měl package-lock.json někde výše ve stromě souborů (pravděpodobně nějakou zálohu, kterou jsem předtím vytvořil). To vedlo k tomu, že Parcel vykazuje všechny druhy podivného chování (nejen to, které je popsáno v tomto čísle). Pokud se tedy rozhodnete vyzkoušet tento přístup a máte pocit, že Parcel „šílí“ zvláštním způsobem, možná by stálo za to zkontrolovat package.json , packaage-lock.json nebo podobné soubory výše ve stromové struktuře souborů.

Celkově je to tedy snadné opravit. Ale to mě málem přimělo (což by byla škoda!) odvrátit se od Parcela, takže jsem sem chtěl zahrnout tuto poznámku.

Ještě více podrobností

Kromě toho jsem vše, co jsem se dozvěděl o procesu / jak je repo strukturováno, zdokumentoval na Notion Page. Pokud se rozhodnete tuto konfiguraci monorepo vyzkoušet, mohlo by se vám to hodit, protože obsahuje všechny příkazy, které potřebujete znát, odkazy na různé důležité zdroje a tak dále.

Autor

Pablo Klaschka (oni/oni)

Working Student, Creative Cloud Platform and Ecosystem Team @ Adobe; Dělám mnoho věcí. Mezi nimi vývoj webových stránek a pluginů pro produkty Adobe, především Adobe XD. Viva la Open-Source!