Konfiguracja testu prób z szynami/pakietem Webpacker

Question

Dodałem webpacker do mojej istniejącej aplikacji szyny, wszystko działa jak urok.

WebPACK config znajduje się pod

config/webpack/shared.js 
config/webpack/development.js 
config/webpack/production.js 

node_modules są instalowane w

vendor/node_modules 

js plików opakowań są w

app/javascript/packs/application.js 

mam zainstalowane reagować i napisał trochę składnik:

app/javascript/discover/example.jsx 

Teraz mam problem z konfiguracją działającego środowiska testowego. Normalnie powiem, że zwykle konfiguracja testu powinna obejmować: karma, jasmine lub mocha, webpack.

Gdzie powinny znajdować się pliki konfiguracyjne? Gdzie będą przechowywane pliki testowe i zbudować karma.config.js, aby połączyć wszystko razem.

Byłoby wspaniale mieć przykładową aplikację, która pokazuje, jak zrobić to wszystko poprawnie, ale oczywiście brakuje mi umiejętności niezbędnych do prawidłowego podłączenia wszystkiego razem.

Nie jest to łatwe do udzielenia pytanie, ale posiadanie takiej przykładowej aplikacji byłoby niezwykle pomocne dla wielu osób, które w przyszłości będą chciały korzystać z pakietu webowego.

Dzięki za wszelkie myśli na ten temat,
Jo

Kilka cennych zasobów:

1. https://medium.com/@scbarrus/how-to-get-test-coverage-on-react-with-karma-babel-and-webpack-c9273d805063#.g6p5go9gd
2. http://qiita.com/kimagure/items/f2d8d53504e922fe3c5c
3. http://nicolasgallagher.com/how-to-test-react-components-karma-webpack/
4. https://www.codementor.io/reactjs/tutorial/test-reactjs-components-karma-webpack

Answer 1

UWAGA: Proces przeszedłem odpowiedzieć na to pytanie nie jest już konieczne, ponieważ zespół szyn ma moved JavaScript dependencies back into the root projektu domyślnie.

---

Ta odpowiedź jest dwuczęściowa. Najpierw wyjaśnię, jak po wielu krwawieniach, potu i łzach dotarłem do mojego obecnego środowiska testowego Webpacker + React + Jest. Po drugie, zanurkowałem dlaczego wszystkie wydatki płyny ustrojowe.

Część 1: Wdrożenie

1. szyn. Wygenerowałem nową aplikację Rails, pomijając wszystkie rzeczy, których prawdopodobnie nie potrzebuję.

   rails new rails-react --skip-action-mailer --skip-active-record --skip-action-cable --skip-javascript --skip-turbolinks 
   

2. Do czasu pojawienia się szyn Rails 5.1, potrzebujemy pakietu Webpacker.

   # Gemfile 
   gem 'webpacker', git: 'https://github.com/rails/webpacker.git' 
   

   Następnie w swojej skorupie

   $ bundle install 
   

3. Konfigurowanie WebPACK i reagować używając Webpacker

   $ rails webpacker:install && rails webpacker:install:react 
   

4. Install żartem i żartach związanych pakiety

   $ bin/yarn add jest babel-jest babel-polyfill react-test-renderer --dev 
   

5. Konfiguruj Jest dobrze gra z Webpackerem. This article przy konfiguracji Jest dla Webpacka jest bardzo pomocny. Według dokumentów "<rootDir> jest specjalnym tokenem, który zostaje zastąpiony przez Jest z katalogiem głównym projektu, a najczęściej jest to folder, w którym znajduje się plik package.json". Najważniejsze dla nas jest to /vendor, a nie /, jak byłoby to w tradycyjnym projekcie JavaScript.

6. Babel. Ten spowodował mi najwięcej bólu głowy. Babel nie obsługuje konfiguracji dynamicznej (chociaż jest to currently being considered). Ponadto sposób, w jaki Babel szuka konfiguracji, nie pomaga nam. "Babel będzie szukał pliku .babelrc w bieżącym katalogu przenoszonego pliku.Jeśli nie istnieje, przejdzie on do drzewa katalogów aż do znalezienia pliku .babelrc lub package.json z" babel ": {} hash within. "

   Sposób, w jaki Babel szuka ustawień, jest również kruchy. Zauważysz, że the babel-handbook documentation for creating presets zawiera krok "po prostu opublikuj to na npm i możesz go użyć tak, jakbyś był dowolnym ustawieniem". Jeśli chcesz, aby Babel rzeczywiście znalazł preset w konwencjonalny sposób, nie ma alternatywy dla używania pakietu npm w katalogu node_modules o nazwie zaczynającej się od babel-preset.

   Oznacza to, że musimy utworzyć plik .babelrc w katalogu głównym Rails, a następnie użyć pełnej ścieżki do każdej potrzebnej wtyczki, w stosunku do tego pliku .babelrc, a nie do skrótu, który będzie wam znany jeśli używasz Babel w przeszłości (np. "presets": ["react"] odnosi się do node_modules/babel-preset-react). Moja .babelrc, zgodnie z żartem Docs na using Webpack 2 i using babel wygląda następująco:

   // .babelrc 
   { 
       "presets": [ 
       "./vendor/node_modules/babel-preset-react", 
       "./vendor/node_modules/babel-preset-es2015" 
       ], 
       "env": { 
       "test": { 
        "plugins": [ 
        "./vendor/node_modules/babel-plugin-transform-es2015-modules-commonjs" 
        ] 
       } 
       } 
   } 
   

   Wyjąć kluczyk options pod konfiguracji babel-loader w config/webpack/shared.js tak że WebPACK wykorzystuje ten plik konfiguracyjny, too.

To doprowadza nas do chwili obecnej. Zaimplementowałem testy sumy (wanilia JS) i Link (React) w dokumentach Jest i uruchom je, wykonując npm run test w katalogu /vendor. Możesz zobaczyć owoce mojej pracy tutaj: https://github.com/pstjean/webpacker-jest

Część 2. Dlaczego?

To nie jest łatwe do zrobienia teraz. Powinno być. Źródłem naszych problemów jest niekonwencjonalna struktura katalogów narzucona przez Webpacker.

Pierwotne uzasadnienie przeniesienia wszystkich plików Przędzy i pakietów Webpack pod numerem /vendor polega na tym, że według DHH posiadanie tych elementów w projekcie jako konwencji nie jest "pięknym sposobem na kojarzenie JS w ramach aplikacji z Railsami aplikacja ". Możesz zobaczyć dyskusję na temat zatwierdzenia implementacji tego here. User lemonmade's comment na tym zatwierdzeniu zapowiada nasze obecne frustracje: "To sprawi, że faktyczne skonfigurowanie jakiegokolwiek narzędzia JavaScript będzie niezwykle trudne i spowoduje, że zachowa się on inaczej niż w jakimkolwiek innym projekcie, który używa pakietów npm".

Downthread, DHH mówi: "Doceń wejście i zachowaj go pod radą, kiedy posuniemy się naprzód." To nie jest przesądzone, ale na razie spróbujemy to zrobić. " Moim zdaniem nie da się tego obronić, i mam nadzieję, że zespół Railsów zda sobie sprawę, że przed wprowadzeniem wersji 5.1 do tego rdzenia. Obecnie istnieje very promising pull request, aby rozwiązać ten problem w projekcie Webpacker. Miejmy nadzieję, że uzyska pewną trakcję!