daxter44
commented
3 years ago @ad-m Spróbowalem usunąć @umijs/fabric z .eslintrc i zastosować się do konfiguracji z tego tutoriala : https://www.robertcooper.me/using-eslint-and-prettier-in-a-typescript-project W wyniku, po uruchomieniu yarn lint otrzymałem oczywiście :
Po zapuszczeniu yarn prettier wprowadził zmiany w 136 plikach z rozszerzeniami .tsx, .ts, .less, .js. Po zmianach otrzymałem wynik :
Zacząłem bawić się wyłączając niektóre role w .eslintrc:
rules: { "react/prop-types": "off", "react/display-name": "off", "@typescript-eslint/explicit-function-return-type": "off", "@typescript-eslint/ban-types": "off", "@typescript-eslint/explicit-member-accessibility": "off", "import/no-cycle": "off", "@typescript-eslint/camelcase": "off", }
W wyniku czego udało mi się zbić liczbę errorów do 17stu.
Pytanie, co z tym zrobić, bo dla zachowania porządku nie chciał bym znacznie wykraczać poza treść issue, także widzę następujące opcje :
- Dalej wyłączać role do uzyskania 0 errorów i wrzucić zmiany w 136 plikach i w ramach następnych issue włączać role ?
- Zamiast poprawiać role, wprowadzić zmiany w plikach aby wszystkie role były spełnione.
- Zastosować jakiś inny gotowy zbiór konfiguracji dla eslinta ? wtedy prosił bym o jakieś naprowadzenie.
ad-m
Myślę, że
@umijs/fabricjest samodzielnie ciekawym kandydatem w kierunku #578. Jedyną rolą biblioteki jest dostarczenie konfiguracji dla linterów. Głęboko wierzę, że lepiej dla nas użyć popularnego standardu niż czerpać od chinczyków egzotycznych. Repozytorium https://github.com/umijs/fabric na GH ma 191 gwiazdek. Mamy przeciętne wymagania, więc nie idźmy w egzotyczne rozwiązania, jeżeli nie jest to konieczne.