Vite+ to brakująca higiena projektu wokół Vite
Vite już bardzo przyspieszył start projektów frontendowych. Problem jest taki, że realny projekt potrzebuje więcej niż dev servera i komendy build. Potrzebuje lintów, formatterów, checków, skryptów i defaultów, które utrzymają repo w porządku po pierwszym popołudniu pracy.
To jest użyteczna część Vite+. Bierze workflow Vite, który już znamy, i dokłada do niego więcej gotowego setupu. Dla wtyczek ma to sens, bo baseline i tak jest wymagający: popup, options page, content script, background service worker, manifest, uprawnienia, reload behavior i finalne pakowanie produkcyjne.
Jeśli starter przynosi też checki i formatowanie, nowy projekt wtyczki zaczyna bliżej kształtu, którego zespół faktycznie może dalej używać.
Co trafiło do CRXJS
PR #1217 dodaje osobną aplikację playgrounds/vite-plus do crxjs/chrome-extension-tools. Używa beta command surface Vite+ i daje repozytorium miejsce, w którym można walidować komendy projektowe przeciwko extension-specific zachowaniu.
Realny kształt MV3
Playground ma popup i content script, a nie tylko dowód, że paczka się instaluje.
Widoczny test w przeglądarce
Content script wstrzykuje przycisk CRXJS i widoczny panel na pasujących stronach.
Checki projektu
Ścieżka walidacji obejmuje komendy Vite+, które mają znaczenie zanim projekt wyjdzie poza starter.
Pętla lokalna w repo
Root script pnpm play:vite-plus ułatwia uruchomienie ścieżki beta z poziomu repo.
To jest celowo małe. I dobrze. Nie chodzi o udawanie, że każda architektura rozszerzenia jest już rozwiązana. Chodzi o sprawdzenie, czy pełniejszy starter Vite+ nadal działa, gdy projektem jest prawdziwe rozszerzenie Manifest V3.
Wartością nie jest nowość, tylko mniej setupu
To nie jest opowieść o rewolucji. Chodzi o zdjęcie z dewelopera nudnego setupu, którego każdy poważny projekt i tak potrzebuje. Jeśli linty, checki, formatowanie, testy i realny kształt wtyczki są obecne od początku, można mniej układać repo, a więcej budować produkt.
Właśnie dlatego warto wrzucić to do CRXJS teraz. Starter jest użyteczny dopiero wtedy, gdy przeżyje pierwszy realny projekt. Jeśli ludzie sprawdzą side panele, wiele content scriptów, options pages, importy service workera, współdzielone UI i pakowanie w CI, zobaczymy, które elementy flow Vite+ pomagają, a które nadal wymagają pracy.
Ciekawe jest to, co ludzie zrobią dalej
Następny etap nie polega na świętowaniu zielonego builda. Chodzi o sprawdzenie, czy ten dodatkowy tooling zmienia pierwszą godzinę pracy nad wtyczką. Czy zespoły szybciej dojdą do działającego popupu i content scriptu? Czy od pierwszego dnia zostawią linty i checki włączone? Czy przestaną kopiować ten sam setup z poprzedniego repo?
To są pytania warte testowania teraz. Playground daje nam miejsce, żeby je zadawać bez udawania, że znamy już wszystkie odpowiedzi.
Co chcemy zobaczyć
- Nowe projekty wtyczek zakładane bezpośrednio na flow Vite+ beta.
- Zgłoszenia pokazujące, które linty, checki, formattery, testy i buildy ludzie faktycznie zostawiają.
- Przykłady pokazujące, jak szybko świeży projekt staje się załadowaną wtyczką w Chromium.
- Przykłady CI, które dowodzą, że finalny dist ładuje się w Chromium.
- Feedback, czy Vite+ usuwa setup, czy tylko przenosi go w inne miejsce.
Jeśli to się uda, wygraną nie będzie efektowna abstrakcja. Wygraną będzie coś nudnego i użytecznego: mniej decyzji setupowych zanim deweloper zacznie budować prawdziwą wtyczkę.
Źródła
Chcesz projekt wtyczki z ogarniętym setupem?
Budujemy rozszerzenia przeglądarkowe i checki CI wokół nich, w tym smoke testy finalnego distu, które łapią problemy zanim zobaczą je użytkownicy.
