VSCode podejście drugie

Ostatnio byłem zmuszony popracować trochę w środowisku VSCode wraz z Salesforce ponieważ mój służbowy laptop postanowił zrobić sobie wakacje. W pewnym momencie się wyłączył i już nie było możliwe aby go włączyć. Zdarza się, to tylko maszyna. Niemniej przez tą sytuację musiałem użyć zapasowego komputera na którym oczywiście nic nie było. 

Na codzień pracuję w IntelliJ + Illuminated Cloud2 więc przesiadka na VSCode była de facto drogą przez mękę. A to skróty klawiszowe nie te, a to zupełnie inne podejście do uruchamiania poleceń. Ciężko i topornie, przynajmniej na pierwszy raz.

Pierwszą rzeczą na jaką się natknąłem to to, że do prawidłowej pracy wtyczki SF potrzebują Javy w wersji 8 lub 11. Żadne inne nie wchodzą w grę. To nawet nie tyle co wszystkie wtyczki co jedna z nich - Apex Language Server.  Tak więc po odnalezieniu odpowiedniej wersji, wrzuceniu gdzie trzeba i dodaniu wpisu do settingów zadowolony chciałem rozpocząć pracę... niestety nie tak szybko... SFDX CLI jest sercem działania wtyczek i wszelki kontakt z orgiem realizowany jest właśnie poprzez to CLI, czy to wywołanie zapytania, czy pobranie logów czy też uruchomienie Anonymous Apexa. 

Po załadowaniu projektu i odświeżeniu definicji obiektów myślałem, że już komfortowo będę mógł pracować... jeszcze tylko mały plugin do skrótów klawiszowych z IntelliJ i jesteśmy w domu. Nic bardziej mylnego. Podczas pracy okazało się, że klasy i to co w nich dopisuję nie są formatowane. Patrzę na dolną belkę - Prettier jest niby uruchomiony jednak nie działa. Szybkie przeanalizowanie problemu - potrzeba NPMa.

Tak więc do poprawnego działania okazało się niezbędne posiadanie również NodeJSa wraz z npm. Szybkie npm install i bum... kolejny problem - jakieś biblioteki są out of date plus jakieś niezgodności w wersjach. Serio, dla człowieka, który mało pracuje z npm może to się wydawać kosmosem. Nie miałem czasu szukać rozwiązania, wybrałem flagę force i uruchomiłem Prettiera. Tutaj pojawił się jednak kolejny problem, zbyt agresywne formatowanie. O ile w IntelliJ kod formatowany jest tak jakby to były klasy Java to w VSCode wszystko  traktowane jest jak kod JSa. Stąd pojawiały się niespójności. Nie mogłem ot tak sformatować całej klasy gdyż w pull requeście wyglądałoby to źle.  Doszedłem w końcu do pewnych metodyk, jak postępować z plikami i ku mojemu zdziwieniu po stworzeniu pull requestu zobaczyłem że cała klasa jest sformatowana - ale jak? Jak to możliwe? Okazuje się, że Prettier ma domyślnie (albo w moim setupie to było - nie wiem) ustawione pre-commit hooki, dzięki czemu formatuje pliki przy commicie. Nieźle. Szybie spojrzenie do dokumentacji i wyłączyłem to. Czy w końcu będzie to ustrojstwo działało jak należy?

Stwierdziłem, że skoro już ogarnąłem setup i formatowanie to teraz już pójdzie z górki. I początkowo nawet to jakoś działało, miałem proste rzeczy do zmiany, przesunięcie kodu z jednego miejsca w inne. Nie wiedziałem więc jeszcze że intellisense jest tutaj ułomny. Pisząc nowy kod przekonałem się, że podpowiadanie składni w tym produkcie właściwie nie istnieje, a jeżeli już działa to podpowiada źle. Co mam na myśli? Na początku miałem wielki problem z podpowiadaniem składni. Okazało się, że w pewnym momencie language server strzelił nullem i wyświetlił piękny stack trace. No cóż, zdarza się. Reload i jedziemy dalej. Ale dalej nie było wcale lepiej. Musiałem pobrać nowe pola z orga, oczywiście nie można pobrać samego pola, trzeba pobrać cały obiekt i pousuwać pozostałości. Może w idealnym świecie nie byłoby różnicy między repo a orgiem ale ten projekt nie był idealny i nie mogłem nadpisać definicji pozostałych pól. Kolejny minus. Kiedy już miałem pole i odświeżyłem definicję obiektów jakoś wtyczka nie chciała mi go w ogóle podpowiadać. Podobnie było z klasami i referencjami. Niektóre działały inne nie. Dodam tylko, że w anonymous apex intellisence w ogóle nie działa a efekt działania kodu (czyli log) ląduje do konsoli (bo leci poprzez CLI). Straszne to wszystko. Inne mniej irytujące rzeczy to brak dokumentacji czy też nie zawsze działające podpowiadanie parametrów.

Kiedy już w bólach i cierpieniu udało mi się napisać kod musiałem go jeszcze zacommitować. Także na tym polu jest wielki problem. Są co prawda wtyczki jak GitLens ale filozofia działania tego wszystkiego to straszna partyzantka. Musiałem się trochę namęczyć aby nauczyć się robienia rebase i stash. Nie dotarłem również do opcji wybierania właściwego kodu przy konfliktach, może tego jeszcze nie ma?

Na koniec zostało mi jeszcze przetestowanie działania debuggera, byłem ciekawy, czy działa podobnie jak w IC. Znalazłem więc opcję na uruchomienie go i ku mojemu zdziwieniu od razu wołał ode mnie logu. Tak więc uruchomiłem test i pobrałem log. Pomijam wygodę tego rozwiązania kiedy jest kilka logów i nie wiadomo, który to który. Debugger działał w miarę dobrze, podobnie jak ten z IC. Jedyna różnica jaką zauważyłem to to, że nie wskakiwał we wbudowane metody. Dobrze też radził sobie z zasobami. W IC po kilku sesjach zżera mi 4-6 GB ramu, tutaj działało to płynnie. Jednak nie posiada jeszcze czegoś takiego jak Run To Cursor. Może kiedyś... Pobieranie logów jest w sumie ok, pojawia się lista, wskazujemy log i ląduje on na dysku. 

Na tą chwilę, dla osoby pracującej na codzień w IC2 przesiadka na VSCode to istny masochizm. Według mnie praca w tym czymś powinna być karą. Salesforce jako lider branży CRM powinien dołożyć wszelkich starań aby praca była przyjemna jednak otrzymujemy coś, co na każdym kroku kuleje i jest toporne. Żeby nie być jedynie krytycznym w stosunku do Salesforcea i ich wtyczek to miałem przyjemność (dosłownie) pracować w VSCode z projektem we Flutterze i to co sobą prezentuje to dzień do nocy z tym co daje nam Salesforce. We Fluterze wszystko działa poprawnie, intellisense, formatowanie kodu, nie potrzeba zbyt wiele konfiguracji. To po prostu działa. Przed Salesforcem jeszcze długa droga, boje się jednak, że nigdy nie uda im się dogonić takich produktów jak IC.