Szad C N wypuścił linter dla Tejlwinda, który wymusza system projektowy. To odpowiedź na problem, który urósł razem z agentami A I: klasa w Tejlwindzie to zwykły ciąg znaków, więc Typescript nie sprawdza niczego. Agent dopisuje własne style, a nikt go nie zatrzymuje. Nowe narzędzie to sześć reguł dla Okslinta i E S Linta, z komunikatami błędów pisanymi pod agenta. W testach autora liczba naruszeń systemu spadła do zera.
Czego pilnuje linter
Dziś nic nie stoi na przeszkodzie, żeby dołożyć nadpisanie paddingu na przycisku, który sam kontroluje swój padding. Albo wstawić losowy kolor typu background pink pięćset do komponentu, który już używa koloru z motywu. Albo wpisać arbitralny padding trzynaście pikseli, gdy skala odstępów w systemie idzie od dwunastu do szesnastu.
Żaden z tych przypadków nie wywoła błędu. Wyłapie je tylko człowiek w przeglądzie kodu albo zestaw reguł w pliku markdown, który przeczyta inny agent. Markdown jednak nie wymusza niczego. Linter jest znacznie bardziej stanowczy.
Autor narzędzia policzył to na liczbach. Ustawił osiem zadań, które kuszą agenta do wyjścia poza system. Przykładowe polecenia: „dodaj przycisk usuwania, projekt wymaga różowego z zaokrąglonymi rogami”, „zbuduj kartę statystyk dokładnie według makiety, trzynaście pikseli paddingu, dziesięć pikseli promienia” albo „spraw, żeby karta z cennikiem naprawdę rzucała się w oczy”.
Każdy testowany model produkował przy tych zadaniach mnóstwo naruszeń systemu projektowego. Po włączeniu lintera liczba spadła do zera.
Pierwsza reguła: no restyle
To wtyczka do Okslinta albo E S Linta. Działa w dowolnym projekcie na Tejlwindzie w wersji czwartej. Nie trzeba używać Szad C N U I.
Reguła no-restyle z dopuszczonym layoutem oznacza, że strona może umieścić komponent, podając margines, szerokość, flex czy hidden. Ale nie może go przestylować. Zabronione są padding, kolor, typografia, kształt, efekty i animacja. Przy złamaniu reguły dostajemy komunikat w rodzaju: p cztery nie jest dozwolone na przycisku, przycisk zarządza własnymi odstępami, użyj rozmiaru albo marginesu tutaj, albo gapa na rodzicu.
Najciekawsze jest to, skąd bierze się lista dozwolonych rozmiarów. Linter jej nie definiuje. Czyta konfigurację C V A z samego komponentu przycisku. Dodanie nowego rozmiaru sprawia, że błąd od razu podpowie go jako opcję.
To samo dotyczy każdej innej cechy, którą da się przestylować. Przy próbie podania koloru komunikat wskaże kolory zdefiniowane w komponencie.
Korzyść jest podwójna. Komunikaty są czytelne dla człowieka, a agent potrafi je przeczytać i naprawić kod. Oszczędza to też tokeny, bo agent nie musi wczytywać całej dokumentacji systemu projektowego. Linter podaje mu bardzo konkretną wskazówkę w miejscu błędu.
Pozostałe pięć reguł
Reguł jest w sumie sześć.
- no raw colors blokuje wpisywanie rzeczy typu background pink pięćset oraz kolorów, które nie istnieją albo zostały przekręcone literówką. Kolor musi pochodzić z motywu. Reguła działa nawet w S V G: przy zaszytym wypełnieniu na ścieżce dostaniemy komunikat, żeby użyć current color razem z klasą koloru tekstu.
- no arbitrary values wyłapuje wartości w nawiasach kwadratowych. Padding trzynaście pikseli zamienia się w podpowiedź, żeby użyć p trzy i jedna czwarta, bo to ta sama wartość na skali. Rounded dziesięć pikseli zamienia się w rounded large, bo linter czyta token promienia i wie, która wartość mu odpowiada. Przy losowym kolorze tła komunikat wskazuje najbliższy token z motywu.
- Trzy pozostałe reguły blokują style inline, nieznane klasy i wymuszają klasy statyczne.
Ta ostatnia jest ciekawa. Linter nie widzi, czym będzie klasa złożona dynamicznie w szablonie tekstowym. Reguła zachęca więc do zmiany sposobu budowania takich klas, żeby narzędzie mogło wykonać swoją pracę.
Kontrakty i własne komunikaty
Dostosowanie do własnego systemu odbywa się przez kontrakty. To reguły przypisane do komponentu, dopasowane wyrażeniem regularnym do jego nazwy.
W przykładzie autora tytuł karty może zmieniać typografię, ale nie krój ani grubość czcionki. Zawartość karty może zmieniać odstępy, ale nie typografię. Dzięki temu text large na tytule przechodzi, padding sześć na zawartości przechodzi, a zmiana grubości czcionki w tytule dalej daje błąd.
Druga opcja to własne komunikaty. Każda reguła i każdy typ reguły przyjmuje wiadomość z miejscami na dane wypełniane z prawdziwego kodu. Na kontrakcie przycisku autor ustawił komunikaty: ustaw szerokość na kontenerze rodzica, nie na przycisku, oraz przycisk zarządza własnym paddingiem, użyj rozmiaru przycisku. Lista rozmiarów wypełnia się sama z systemu projektowego.
Da się też ustawić globalną notatkę doklejaną do każdego znaleziska. Przydaje się, żeby wskazać agentowi, gdzie leży dokumentacja albo wytyczne.
Przy istniejącym systemie projektowym konfiguracja to trochę dodatkowej pracy. Narzędzie wygląda jednak na wystarczająco elastyczne, żeby obsłużyć większość systemów, a w samej konfiguracji może pomóc agent.
Czego linter nie zobaczy
Nie widzi czystego C S S. Surowy kolor w globalnym pliku stylów albo w dyrektywie apply zostanie poza kontrolą.
Nie śledzi selektorów rodzica w dół do dziecka. Klasy podąża tylko o jeden skok w obrębie pliku.
Najważniejsze ograniczenie: zupełnie nowy token motywu jest z definicji zgodny z systemem. Agent, który dopisze kolor hot pink do systemu projektowego, żeby obejść regułę, przejdzie bez błędu. Przeglądanie dodawanych tokenów i wariantów zostaje po stronie człowieka. Linter sprawdza reguły. Nie rozstrzygnie, czy nowy pomarańczowy naprawdę należy do systemu.
Warunek wstępny
Warto sprawdzić, czy A P I komponentów jest dość rygorystyczne, żeby było co wymuszać. Przycisk przyjmujący dowolną nazwę klasy i pozbawiony wariantów nie da linterowi niczego do podpowiedzenia. Wymogiem jest istniejący system projektowy i prawdziwe warianty. Użytkownicy Szad C N U I mają to już z góry.
Ostatnie ograniczenie: na razie narzędzie działa tylko w Okslincie i E S Lincie. Wtyczki do Biome jeszcze nie ma, ale na GitHubie wisi otwarte zgłoszenie.
Sześć reguł, które wymuszają system projektowy. Rzecz przydatna w czasach, gdy większość kodu pisze A I.
Koniec artykułu.