← Wszystkie tematy W 23% ogłoszeń · 11 z 47 ogłoszeń frontend React

Monorepo i integracja aplikacji

Jeden duży pokój z półkami dla każdego

Monorepo i integracja aplikacji pojawiają się w 11 z 47 ogłoszeń, często z nazwami Nx, Turborepo albo Module Federation. Pytają, po co to i jak nie zabić czasu buildów.

Przerobione Opanowane 0 z 3 pytań

Ucz się z Claude Wytłumacz od zera Próbna rozmowa Zadanie praktyczne Ściąga na 1 stronę

Co piszą w ogłoszeniach

„praktyczna znajomość środowiska monorepo z wykorzystaniem Turborepo i pnpm – minimum 1 rok doświadczenia lub 2 projekty”
Randlab · React Developer – (K/M/N)
„Minimum rok doświadczenia w pracy z architekturą monorepo, z wykorzystaniem Turborepo oraz menedżera pakietów pnpm,”
GET IT TOGETHER Sp. z o.o. · Frontend Developer (React)
„Architektura: Monorepo (Nx), Architektura Mikrofrontendowa (Microfrontends)”
Eko-Okna S.A. · Frontend Developer (Senior React)

Scena · zmiana we wspólnej paczce

Jeden duży pokój z półkami

Trzy zespoły mają trzy aplikacje i dzielą się klockami: ui (przyciski), utils (pomocnicze funkcje) i api-client. W polyrepo każdy mieszka w osobnym domu i klocki wysyła się pocztą (npm). W monorepo wszyscy mieszkają w jednym dużym pokoju z półkami. Zmień wspólny klocek i zobacz, co się dzieje.

polyrepo monorepo

–

Zmień ui w polyrepo, potem w monorepo.

Porównajmy

Osobne domy czy jeden pokój?

	Polyrepo	Monorepo
Wspólny klocek	Wysyłany pocztą.Publikacja paczki do npm, potem bump wersji w każdym repo.	Leży na półce obok.Workspaces (pnpm, npm, yarn): import prosto ze źródła.
Zmiana w ui	Kilka PR-ów w kilku repo.Każda aplikacja aktualizuje się w swoim tempie, wersje się rozjeżdżają.	Jeden PR.Atomowa zmiana: paczka i wszystkie aplikacje naraz, CI testuje całość.
Breaking change	Wychodzi po tygodniach.Gdy któryś zespół w końcu zrobi bump.	Wychodzi od razu w CI.Typy i testy wszystkich konsumentów w tym samym PR.
Czas buildów	Każde repo małe i szybkie.	Duże, więc potrzebne narzędzia.Turborepo / Nx: tylko „affected”, cache zadań lokalny i zdalny.
Własność i dostęp	Proste: repo = zespół.Osobne uprawnienia i release.	Trzeba ustalić granice.CODEOWNERS, reguły zależności (Nx tags), niezależne deploye aplikacji.

Jeden pokój

Wspólne klocki leżą na półce obok, nie trzeba ich wysyłać pocztą.

Tylko to, co dotknięte

Buduj i testuj paczkę, którą zmieniłeś, i tych, którzy z niej korzystają. Resztę weź z cache.

Jedna zmiana, jeden PR

Klocek i wszystkie aplikacje zmieniają się razem, więc wersje się nie rozjeżdżają.

Sprawdź się

Pytania z rozmów

Najpierw odpowiedz na głos, dopiero potem rozwiń odpowiedź.

Monorepo vs polyrepo: plusy i minusy?

Moja odpowiedź

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż odpowiedź

Dla przedszkolaka: Osobne domy, w których klocki wysyła się pocztą, albo jeden duży pokój z półkami, gdzie wspólne klocki leżą obok.

Na rozmowę: Monorepo: atomowe zmiany przez wiele paczek i aplikacji w jednym PR, łatwe współdzielenie kodu bez publikacji, jedna konfiguracja narzędzi, refaktor widoczny od razu w CI. Wymaga narzędzi do skali (Nx, Turborepo, pnpm workspaces), granic i właścicieli (CODEOWNERS, reguły zależności), sensownego CI (affected, remote cache). Polyrepo: proste uprawnienia i niezależne wydania, małe repo, ale wspólny kod idzie przez publikację na npm, wersje się rozjeżdżają, a zmiany przekrojowe to wiele PR-ów.

Umiem?

Zapytaj Claude Rozwiń Przepytaj mnie Pytania pogłębiające

Jak działa Module Federation i kiedy mikrofrontendy mają sens?

Moja odpowiedź

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż odpowiedź

Dla przedszkolaka: Każdy zespół buduje swój pokój osobno i dostarcza go w dowolnym momencie, a dom składa się z nich dopiero, gdy ktoś do niego wchodzi.

Na rozmowę: Module Federation (webpack 5, Rspack, plugin do Vite) pozwala aplikacji host ładować w runtime moduły wystawione przez inne, niezależnie budowane i wdrażane aplikacje (remotes), ze współdzielonymi singletonami (react, react-dom). Mikrofrontendy mają sens przy wielu zespołach z osobnymi cyklami wydań i dużej organizacji, gdzie niezależne wdrażanie jest ważniejsze niż prostota. Koszty: zgodność wersji współdzielonych bibliotek, spójność UI (design system), wydajność (wiele bundli), trudniejsze testy i debugowanie. Dla jednego zespołu zwykle wystarcza monorepo z modułami.

Umiem?

Zapytaj Claude Rozwiń Przepytaj mnie Pytania pogłębiające
Jak działają „affected” i cache zadań w Turborepo lub Nx?

Moja odpowiedź

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż odpowiedź

Dla przedszkolaka: Gdy zmienisz jeden klocek, sprawdzasz tylko ten klocek i wieże, które na nim stoją. Wieże, których nikt nie dotknął, mają już stempel „sprawdzone”.

Na rozmowę: Narzędzie zna graf zależności między projektami (z package.json / project.json). Affected porównuje zmiany względem bazowego commita (nx affected -t build, turbo run build --filter=...[origin/main]) i uruchamia zadania tylko dla zmienionych projektów i ich zależnych. Cache liczy hash wejść zadania (pliki, zależności, zmienne środowiskowe, wersja narzędzi) i przy trafieniu odtwarza wyniki i logi bez wykonania. Remote cache (Nx Cloud, Vercel Remote Cache) dzieli te wyniki między developerów i CI.

Umiem?

Zapytaj Claude Rozwiń Przepytaj mnie Pytania pogłębiające

Poziom wyżej

Wersja dla seniora

Tak wyglądają pytania na seniora i leada: nie ma jednej dobrej odpowiedzi, liczy się to, jak ważysz kompromisy i czy mówisz o skali, ryzyku i ludziach.

Przypadek 1

Przeniesienie 12 repozytoriów do jednego monorepo

Firma ma 12 repozytoriów frontendowych: 5 aplikacji, bibliotekę komponentów, klienta API i kilka paczek narzędziowych. Zmiana w bibliotece wymaga publikacji na npm i 5 PR-ów aktualizujących wersje, co trwa tydzień. CTO chce monorepo w tym kwartale, a zespoły boją się utraty historii i zablokowania pracy.

Zanim rozwiniesz: powiedz na głos, jak byś to rozwiązał, i nazwij co najmniej jeden kompromis.

Moje rozwiązanie

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż, czego szuka rekruter, i modelową odpowiedź

Co sprawdza rekruter

Czy planujesz migrację przyrostowo i bez zatrzymania pracy
Czy znasz narzędzia i wiesz, co dokładnie dają
Czy myślisz o historii gita, CI, właścicielach i komunikacji

Odpowiedź seniora

Wybór narzędzia: pnpm workspaces jako fundament, a nad tym Nx albo Turborepo dla grafu zależności, cache zadań i budowania tylko zmienionych projektów. Nx daje więcej (generatory, reguły granic), Turborepo jest prostszy. Wybieram na podstawie potrzeb, nie mody.

Kolejność: najpierw szkielet monorepo z CI, cache zdalnym i wspólną konfiguracją TS i ESLint. Potem przenoszę paczki od dołu grafu: klient API i biblioteka komponentów, bo na nich zyskujemy najwięcej. Historię zachowuję przez git subtree lub git filter-repo do podkatalogu. Każda aplikacja przechodzi osobno w uzgodnionym oknie, a stare repo zostaje w trybie tylko do odczytu z linkiem.

Od pierwszego dnia: CODEOWNERS dla katalogów, wymagane checki tylko dla projektów dotkniętych zmianą (nx affected) i budżet czasu CI. Mierzę czas od zmiany w bibliotece do wdrożenia w aplikacjach, przed i po.

Typowe wpadki

Przeniesienie wszystkiego w jeden weekend
Monorepo bez cache i affected, przez co CI buduje wszystko przy każdej zmianie
Brak właścicieli katalogów i chaos w review

Dopytają o

Jak rozwiążesz konflikty wersji zależności między aplikacjami?
Co z aplikacją, której zespół nie chce się przenieść?
Jak zapewnisz, że repo nie urośnie do rozmiaru, który spowalnia gita?

Zapytaj Claude Rozwiń case Zagraj interviewera

Przypadek 2

Zespoły importują sobie nawzajem kod z głębi folderów

Po roku w monorepo aplikacja sklepu importuje komponenty bezpośrednio z apps/panel/src/components, a dwie biblioteki mają zależność cykliczną. Każda zmiana w panelu psuje build sklepu i nikt nie wie, kto za co odpowiada.

Zanim rozwiniesz: powiedz na głos, jak byś to rozwiązał, i nazwij co najmniej jeden kompromis.

Moje rozwiązanie

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż, czego szuka rekruter, i modelową odpowiedź

Co sprawdza rekruter

Czy umiesz egzekwować granice narzędziami, a nie tylko umową
Czy znasz pojęcie publicznego API paczki
Czy wiesz, jak naprawić istniejący bałagan stopniowo

Odpowiedź seniora

Granice muszą być sprawdzane automatycznie. Każdy projekt ma publiczne API przez index.ts i pole exports w package.json, a głębokie importy są blokowane. W Nx robię to tagami projektów (scope:shop, type:ui, type:feature) i regułą @nx/enforce-module-boundaries, w innych narzędziach przez eslint-plugin-boundaries lub dependency-cruiser. Aplikacje nigdy nie importują z innych aplikacji, wspólny kod przenoszę do libs.

Istniejący stan naprawiam etapami: włączam regułę jako ostrzeżenie, generuję listę naruszeń, zamrażam ich liczbę w CI (nie może rosnąć) i spłacam po kawałku. Cykle rozbijam przez wydzielenie wspólnej części do nowej biblioteki albo odwrócenie zależności.

Własność: CODEOWNERS dla każdego katalogu i opis projektu z właścicielem w project.json. Graf zależności (nx graph) pokazuję na przeglądach architektury.

Typowe wpadki

Strona w Confluence z zasadami bez egzekwowania w CI
Włączenie reguły jako błąd od razu i zablokowanie wszystkich PR-ów
Kopiowanie komponentu zamiast wydzielenia biblioteki

Dopytają o

Jak zdecydujesz, czy coś jest wspólne, czy powinno zostać w aplikacji?
Jak wersjonujesz biblioteki wewnątrz monorepo?
Kto zatwierdza zmiany w bibliotece używanej przez 6 zespołów?

Zapytaj Claude Rozwiń case Zagraj interviewera

Przypadek 3

Biblioteka z monorepo musi być publikowana dla klientów zewnętrznych

SDK do osadzania widżetu płatności rozwijacie w monorepo razem z aplikacjami. Wewnątrz zawsze używacie najnowszej wersji z workspace, ale partnerzy instalują je z npm i po ostatniej zmianie integracja u dwóch partnerów przestała działać.

Zanim rozwiniesz: powiedz na głos, jak byś to rozwiązał, i nazwij co najmniej jeden kompromis.

Moje rozwiązanie

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż, czego szuka rekruter, i modelową odpowiedź

Co sprawdza rekruter

Czy odróżniasz wersjonowanie wewnętrzne od publicznego
Czy znasz semver, changesets i kontrolę publicznego API
Czy myślisz o kompatybilności wstecznej i komunikacji z klientami

Odpowiedź seniora

Paczki wewnętrzne mogą zostać na workspace:*, ale publiczne SDK potrzebuje dyscypliny. Wprowadzam Changesets: każdy PR zmieniający SDK musi mieć changeset z typem zmiany, a publikacja i changelog dzieją się w CI. Breaking change oznacza major.

Żeby nie przegapić breaking change, kontroluję publiczne API automatycznie: API Extractor albo snapshot typów (.d.ts) w CI, który pokazuje każdą zmianę sygnatury do review. Do tego testy kontraktowe na przykładowej integracji partnera i budowanie przeciw minimalnej wspieranej wersji zależności peer.

Wydania: kanał next lub beta dla partnerów, którzy chcą testować wcześniej, okres deprecation z ostrzeżeniami w konsoli i dokumentacja migracji. Po incydencie: hotfix przywracający poprzednie zachowanie jako patch, a zmiana wraca jako major.

Typowe wpadki

Publikowanie z laptopa developera
Uznanie zmiany typu za nieistotną, bo „w JS działa”
Brak kanału beta dla partnerów

Dopytają o

Jak zbudujesz paczkę, żeby działała w ESM i CommonJS?
Jak długo wspierasz starą wersję majora?
Jak dowiesz się, z której wersji korzystają partnerzy?

Zapytaj Claude Rozwiń case Zagraj interviewera

Przypadek 4

Monorepo czy Module Federation dla 4 zespołów i jednego portalu

Portal klienta składa się z 4 obszarów rozwijanych przez 4 zespoły. Zespoły chcą wdrażać niezależnie, kilka razy dziennie. Jeden architekt proponuje mikrofrontendy z Module Federation, drugi jedno monorepo z jedną aplikacją. Masz zarekomendować rozwiązanie.

Zanim rozwiniesz: powiedz na głos, jak byś to rozwiązał, i nazwij co najmniej jeden kompromis.

Moje rozwiązanie

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż, czego szuka rekruter, i modelową odpowiedź

Co sprawdza rekruter

Czy rozumiesz, że monorepo i mikrofrontendy rozwiązują różne problemy
Czy znasz koszty runtime’owej integracji
Czy decyzję opierasz na potrzebach organizacji

Odpowiedź seniora

To dwie różne osie. Monorepo dotyczy organizacji kodu i współdzielenia, Module Federation dotyczy niezależnych wdrożeń i składania aplikacji w przeglądarce. Można mieć oba.

Pytam o realną potrzebę: czy zespoły naprawdę blokują się na wspólnym wdrożeniu, czy problemem jest wolny pipeline i brak testów. Jeśli to drugie, jedna aplikacja w monorepo z affected build, feature flagami i szybkim CI daje większość korzyści bez kosztów. Module Federation dodaje złożoność: wersjonowanie współdzielonych zależności (singleton React), kontrakty między hostem i remote’ami, obsługę błędów ładowania, testy integracyjne na produkcyjnej kompozycji i wolniejszy start.

Jeśli niezależne wdrożenia są faktycznym wymogiem (różne cykle wydań, różne firmy), wybieram Module Federation w monorepo: wspólne biblioteki i design system w libs, każdy remote jako osobny projekt z własnym deployem, kontrakty typowane i testowane w CI. Decyzję zapisuję w ADR z kryteriami ponownej oceny.

Typowe wpadki

Mikrofrontendy, bo „tak robi duża firma”
Brak planu na współdzielone zależności i różne wersje Reacta
Utożsamianie monorepo z jednym deployem

Dopytają o

Jak przetestujesz, że nowa wersja remote’a nie psuje hosta?
Jak zapewnisz spójny wygląd między obszarami?
Co z wydajnością, gdy każdy remote ładuje własne zależności?

Zapytaj Claude Rozwiń case Zagraj interviewera