Skip to content

Project settings tutorial

Paweł edited this page Jan 21, 2021 · 2 revisions

https://docs.google.com/document/d/1naOuhQkPJfJT0M7QBb_VkimPeLkU3XtZD4JoGYuPs40/edit?usp=sharing - wersja sformatowana

Wersja skopiowana z doc'a: Krok po kroku co zostało zrobione

Package.json (częściowo) oraz inne pliki typu: gitignore, prettierrc (dodana jedna linijka: "printWidth": 140 - określa długość linii, po której nastąpi jej złamanie), .babelrc skopiowane z projektu JS.

Również podstawowe scss’y zostały skopiowane i spróbowaliśmy wczoraj zrobić jakiś podstawowy podział na foldery (zobaczymy jak wyjdzie) UPDATE: po naszym wspólnym spotkaniu foldery zaktualizowane wg Mateusza.

Dodany plik .eslintrc.js (konfiguracja ESLinta - Mateusz dał od siebie z jakiegoś projektu konfigurację) Generalnie ESLint z Prettier służą do dobrego formatowania kodu.

Więcej info: https://www.robertcooper.me/using-eslint-and-prettier-in-a-typescript-project https://khalilstemmler.com/blogs/typescript/eslint-for-typescript/

package.json

W zasadzie interesuje nas ten fragment:

Generalnie komendy te same co w tamtym projekcie: npm run start:dev rusza projekt na porcie 7575 i to już parcel dla o nasłuchiwanie (ts --watch) i bieżącą kompilację npm run test / npm test / npm test nazwa_pliku : testy poprzez ts-test (konfiguracja testów poniżej) Inne komendy: npm clean - jakby ktoś chciał wyczyścić folder .cache, coverage,dist i node_modules npm build - budowanie projektu, czyli wszystkie nasze pliki, które pójdą na server znajdą się w folderze dist, w formie zupełnie niezrozumiałej, a to właśnie chodzi, żeby nikt kodu nie podpierdzielił. npm test:watch / npm test:cov - no to odpalamy albo watcha na testach albo ich pokrycie, czyli ta tabelka procentowa w konsoli się pojawi, ale to przerabialiśmy w materiałach :-)

tsconfig.json

Przydatne linki: dokumentacja tsconfig.json: https://www.staging-typescript.org/tsconfig#forceConsistentCasingInFileNames

Źródło do punktów 3 i w dół: https://www.youtube.com/watch?t=8465&v=BwuLxPH8IDs&feature=youtu.be&ab_channel=Academind

Wpisane tsc --init (utworzenie tsconfig.json - zrobienie projektu TS’owego)

W pliku tsconfig.json:

“sourceMap”: true - do debuggowania (https://www.youtube.com/watch?t=8465&v=BwuLxPH8IDs&feature=youtu.be&ab_channel=Academind)

“outDir”: “./dist” - chodzi o to, żeby nasze pliki TS nie tworzyły się obok, a w folderze dist

“rootDir”: “./src” - żeby pliki do kompilacji na JS brał tylko z folderu src (UPDATE: jednak tego nie ma, bo mamy też pliki TS poza folderem src np. testy i wyrzucało błąd)

“removeComments” : true - żeby nie przerzucał z TSa do JSa naszych komentarzy

“noEmitOnError”: true - jeżeli mamy jakiś błąd w pliku TS to nie zostanie on przekompilowany na JS

“strict”: true zostaje, żeby wszystkie opcje z “Strict Type-Checking Options” były domyślnie włączone na true https://www.youtube.com/watch?t=8465&v=BwuLxPH8IDs&feature=youtu.be&ab_channel=Academind

“strictPropertyInitialization”: true (jest tak domyślnie przez 4.5), żeby tworząc klasy i ich zmienne, trzeba było od razu przypisać zmiennej wartość(lub w konstruktorze). Żebyśmy nie mieli klas z pustymi zmiennymi :-) Więcej info: https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-7.html#strict-class-initialization Są proste i przejrzyste przykłady - też jak to ominąć, jeżeli chcemy na siłę zostawić zmienną z undefined... Powyższy pkt napisałem, ponieważ w filmiku Academind zostało to przeskoczone :-)

Zastanawiam się nad:

Wytłumaczone tutaj: https://www.youtube.com/watch?v=BwuLxPH8IDs&t=11199s&ab_channel=Academind Generalnie chodzi o to, żeby rzucało błędem jak będą w kodzie jakieś nieużyte parametry metod, zmienne lokalne, bądź nie wszystkie ścieżki w funkcjach dają return. Co myślicie? (chociaż mogą być sytuacje, że będziemy pisać funkcje z parametrami i ich na razie nie wykorzystamy, bo ktoś inny potem będzie tego używał….więc?) UPDATE: odkomentowane i jakby pojawiały się jakieś skrajne sytuacje, to możemy zakomentować…..oooł raaajt?

UPDATE: tego jednak nie ma…. bo parcel to robi Dodane “compileOnSave”: true - The compileOnSave property can be used to direct the IDE to automatically compile the included TypeScript files and generate the output. KOMPILATOR TO ODRZUCA…. https://github.com/typed-ember/ember-cli-typescript/issues/23

dodane “forceConsistentCasingInFileNames”: true wytłumaczone tu: https://www.staging-typescript.org/tsconfig#forceConsistentCasingInFileNames chodzi o to, że musimy importować pliki z dokładną nazwą i wielkością liter taką jak w nazwie, inaczej odrzuci

dodane “skipLibCheck”: true https://www.staging-typescript.org/tsconfig#skipLibCheck sprawdza czy pliku zadeklarowane jako .ts są zgodne z plikami js (tak czy inaczej mało ważne)

Testy testy zgodnie z filmikiem: https://www.youtube.com/watch?v=dusrMr9sVB8&ab_channel=JSD%C5%BCem od 2:10 do 7:50 … u nas wygląda to tak: package.json (tu znajduje się opis jak ma działać Jest u nas - po nazwach idzie się w sumie domyślić co do czego jest):

Mateusz też podrzucił ten “transform”, bo coś nie łapało dobrze (chyba z importami plików w testach był problem). Jakaś dodatkowa konfiguracja, która na to pozwala…. jak ktoś chce poczytać więcej: https://jestjs.io/docs/uk/next/code-transformation oraz https://github.com/kulshekhar/ts-jest/issues/642

oraz setupFiles, czyli setupJest (1 linia w tym pliku z poprzedniego projektu, reszta z filmiku). Generalnie plik konfiguracyjny Jest - widać, że tutaj zamiast zwykłego Jest ma się wywoływać ts-jest :-)

Clone this wiki locally