Discussion:
Debugowanie JS w VSCode
(Wiadomość utworzona zbyt dawno temu. Odpowiedź niemożliwa.)
Roman Tyczka
2018-07-30 09:19:03 UTC
Permalink
Witam,

W JS jestem zielony, ale muszę coś zrobić, więc próbuję zorganizować
środowisko.
Wybrałem edytor VS Code, zainstalowałem NodeJS, skonfigurowałem VSC:

"configurations": [
{
"type": "node",
"request": "launch",
"name": "Launch Program",
"program": "${workspaceFolder}/Tss/TssClient.js",
"cwd": "${workspaceFolder}",
"runtimeExecutable": "t:\\tools\\NodeJS\\x64\\"
},

I teraz zakładam pułapki, odpalam skrypt i nic, pojawia się na pół sekundy
toolbar debugera i koniec działania, a w debug console mam:

t:\tools\NodeJS\x64\ --inspect-brk=44200 Tss\TssClient.js
Node process
error: Error: spawn t:\tools\NodeJS\x64\ ENOENT

Co robię źle?
Czy fakt, że VSCode używa NodeJS do debugowania i odpalania skryptów
wymusza jakiś specjalny sposób pisania tych skryptów?
--
pozdrawiam
Roman Tyczka
Borys Pogoreło
2018-07-30 12:03:37 UTC
Permalink
Post by Roman Tyczka
"runtimeExecutable": "t:\\tools\\NodeJS\\x64\\"
Nie znam tej aplikacji, ale jak dla mnie w powyższym brakuje Ci pełnej
ścieżki do node.exe
--
Borys Pogoreło
borys(#)leszno,edu,pl
Roman Tyczka
2018-07-30 12:44:52 UTC
Permalink
Post by Borys Pogoreło
Post by Roman Tyczka
"runtimeExecutable": "t:\\tools\\NodeJS\\x64\\"
Nie znam tej aplikacji, ale jak dla mnie w powyższym brakuje Ci pełnej
ścieżki do node.exe
No widzisz, rzut oka praktyka i jestem krok dalej, dzięki :-)

Kolejne pytanie.
Mam skrypt, który korzysta z jQuery, w przeglądarce skrypty się "widzą"
wzajemnie, więc mój skrypt może się odwoływać do jQuery i z niego
korzystać, w przypadku VSCode i NodeJS debuger nie "widzi" klas jQuery.
Masz pomysł jak to ominąć? Googluje i nic sensownego nie mogę osiągnąć.

ps. czy mógłbyś polecić inne środowisko do debugowania JS?
--
pozdrawiam
Roman Tyczka
Borys Pogoreło
2018-07-30 22:08:41 UTC
Permalink
Post by Roman Tyczka
Mam skrypt, który korzysta z jQuery, w przeglądarce skrypty się "widzą"
wzajemnie, więc mój skrypt może się odwoływać do jQuery i z niego
korzystać, w przypadku VSCode i NodeJS debuger nie "widzi" klas jQuery.
Masz pomysł jak to ominąć? Googluje i nic sensownego nie mogę osiągnąć.
Wszystko zależy od tego w jaki sposób sięgasz do jQuery i jak się do niej
później odwołujesz. W przeglądarce zapewne wrzucasz tę bibliotekę do
globalnej przestrzeni nazw (czy też raczej do obiektu window), w node jej
nie masz - musisz bibliotekę zaimportować i korzystać z tak stworzonej
zmiennej. Najlepiej wrzuć kawałek swojego kodu.
Post by Roman Tyczka
ps. czy mógłbyś polecić inne środowisko do debugowania JS?
Chrome devtools ;) Zależy co chcesz uzyskać. Korzystasz z node, ale nie
wiem czy faktycznie chcesz budować aplikację node, czy tylko ten debugger
tak działa.
--
Borys Pogoreło
borys(#)leszno,edu,pl
Roman Tyczka
2018-08-02 12:35:33 UTC
Permalink
Post by Borys Pogoreło
Post by Roman Tyczka
Mam skrypt, który korzysta z jQuery, w przeglądarce skrypty się "widzą"
wzajemnie, więc mój skrypt może się odwoływać do jQuery i z niego
korzystać, w przypadku VSCode i NodeJS debuger nie "widzi" klas jQuery.
Masz pomysł jak to ominąć? Googluje i nic sensownego nie mogę osiągnąć.
Wszystko zależy od tego w jaki sposób sięgasz do jQuery i jak się do niej
później odwołujesz. W przeglądarce zapewne wrzucasz tę bibliotekę do
globalnej przestrzeni nazw (czy też raczej do obiektu window), w node jej
nie masz - musisz bibliotekę zaimportować i korzystać z tak stworzonej
zmiennej. Najlepiej wrzuć kawałek swojego kodu.
Sprawa wygląda tak, mam serwer restowy (napisany w Delphi), teraz chcę się
do niego podłączyć z JS. W JS napisałem przy użyciu jQury swoją klasę
klienta tegoż serwera restowego, ta klasa jest w pliku TssClient.js i
chciałbym ją podebugować, potestować. Ale marzy mi się środowisko
zintegrowane do jakiego mnie przyzwyczaiło Delphi (czy nawet PHP), z
debugerem, wygodnym edytorem, etc. Dlatego po chwili googlowania wybrałem
VS Code, ale może to błąd.
Post by Borys Pogoreło
Post by Roman Tyczka
ps. czy mógłbyś polecić inne środowisko do debugowania JS?
Chrome devtools ;) Zależy co chcesz uzyskać. Korzystasz z node, ale nie
wiem czy faktycznie chcesz budować aplikację node, czy tylko ten debugger
tak działa.
Nie chcę aplikacji node tylko właśnie VS Code tak działa. Dlatego pytałem o
inne sensowne środowisko, które nie jest przeglądarką. Może czegoś takiego
po prostu nie ma?

ps. NodeJS ma coś takiego jak moduły i można podobnie jak w PHP stosować
funkcję require(), ale to wymaga po stronie inkludowanego skryptu
zarejestrowania exportu, a przecież nie dopiszę do jQuery tego.

https://www.w3schools.com/nodejs/nodejs_modules.asp
--
pozdrawiam
Roman Tyczka
Borys Pogoreło
2018-08-02 18:36:29 UTC
Permalink
Post by Roman Tyczka
Nie chcę aplikacji node tylko właśnie VS Code tak działa. Dlatego pytałem o
inne sensowne środowisko, które nie jest przeglądarką. Może czegoś takiego
po prostu nie ma?
Jest, jest. Skoro chcesz to zrobić tak, to możesz się po prostu podłączyć
pod debugger wbudowany w node. Większość IDE to zapewnia:

https://nodejs.org/en/docs/guides/debugging-getting-started/#inspector-clients
Post by Roman Tyczka
ps. NodeJS ma coś takiego jak moduły i można podobnie jak w PHP stosować
funkcję require(), ale to wymaga po stronie inkludowanego skryptu
zarejestrowania exportu, a przecież nie dopiszę do jQuery tego.
Wiele pakietów jest dostosowanych do takiego użycia, w tym jQuery:

https://www.npmjs.com/package/jquery#node
--
Borys Pogoreło
borys(#)leszno,edu,pl
Roman Tyczka
2018-08-03 12:29:40 UTC
Permalink
Post by Borys Pogoreło
Post by Roman Tyczka
Nie chcę aplikacji node tylko właśnie VS Code tak działa. Dlatego pytałem o
inne sensowne środowisko, które nie jest przeglądarką. Może czegoś takiego
po prostu nie ma?
Jest, jest. Skoro chcesz to zrobić tak, to możesz się po prostu podłączyć
https://nodejs.org/en/docs/guides/debugging-getting-started/#inspector-clients
Odpuszczam Node, to zbyt dla mnie zagmatwane i przerośnięte. Zwłaszcza, że
odkryłem iż VSCode pozwala jednak na "lokalne" debugowanie, trzeba w nim
doinstalować rozszerzenie debugera dla Chrome lub Firefoxa, odpalić tę
przeglądarkę z parametrem --remote-debugging-port=9222 i się podłączyć
edytorem do przeglądarki, która ma API od debugowania, wtedy można w miarę
wygodnie debugować kod w sensownym edytorze choć wykonuje się po stronie
przeglądarki. Ale lepsze to niż debugowanie w samej przeglądarce.

W sumie to mnie trochę dziwi, że najpopularniejszy język świata nie ma
jakichś prostych IDE z wbudowanym debugerem i całą otoczką narzędzi
developerskich tylko trzeba się tak gimnastykować.
Post by Borys Pogoreło
Post by Roman Tyczka
ps. NodeJS ma coś takiego jak moduły i można podobnie jak w PHP stosować
funkcję require(), ale to wymaga po stronie inkludowanego skryptu
zarejestrowania exportu, a przecież nie dopiszę do jQuery tego.
https://www.npmjs.com/package/jquery#node
No to już niepotrzebne i działa tak jak chciałem. Tymczasem kolejne
problemy i nowy wątek :-)
--
pozdrawiam
Roman Tyczka
Borys Pogoreło
2018-08-03 13:30:45 UTC
Permalink
Post by Roman Tyczka
W sumie to mnie trochę dziwi, że najpopularniejszy język świata nie ma
jakichś prostych IDE z wbudowanym debugerem i całą otoczką narzędzi
developerskich tylko trzeba się tak gimnastykować.
Cóż, jaki język, takie narzędzia ;)
--
Borys Pogoreło
borys(#)leszno,edu,pl
Roman Tyczka
2018-08-03 13:47:44 UTC
Permalink
Post by Borys Pogoreło
Post by Roman Tyczka
W sumie to mnie trochę dziwi, że najpopularniejszy język świata nie ma
jakichś prostych IDE z wbudowanym debugerem i całą otoczką narzędzi
developerskich tylko trzeba się tak gimnastykować.
Cóż, jaki język, takie narzędzia ;)
E, nie taki zły, podoba mi się jego ekspresja i elastyczność.
Mam fajną książkę "JS, mocne strony" Crockforda i koleś opisuje to co uważa
za udane i dobre w JS przestrzegając przed niedoróbkami i błędami w
implementacji standardu (błędy już w definicji). Bardzo fajna pozycja, z
dystansem i bez wychwalania.
--
pozdrawiam
Roman Tyczka
Borys Pogoreło
2018-08-03 17:59:22 UTC
Permalink
Post by Roman Tyczka
Post by Borys Pogoreło
Cóż, jaki język, takie narzędzia ;)
E, nie taki zły, podoba mi się jego ekspresja i elastyczność.
Mam fajną książkę "JS, mocne strony" Crockforda i koleś opisuje to co uważa
za udane i dobre w JS przestrzegając przed niedoróbkami i błędami w
implementacji standardu (błędy już w definicji). Bardzo fajna pozycja, z
dystansem i bez wychwalania.
Loading Image... ;)

Jeszcze zapłaczesz nad tym językiem. Zacznij od razu uczyć się Typescriptu
- prosta rzecz, a przynajmniej mocno ograniczysz problemy wynikające z
niejawnych konwersji typów.
--
Borys Pogoreło
borys(#)leszno,edu,pl
Roman Tyczka
2018-08-04 20:42:11 UTC
Permalink
Post by Borys Pogoreło
Post by Roman Tyczka
E, nie taki zły, podoba mi się jego ekspresja i elastyczność.
Mam fajną książkę "JS, mocne strony" Crockforda i koleś opisuje to co uważa
za udane i dobre w JS przestrzegając przed niedoróbkami i błędami w
implementacji standardu (błędy już w definicji). Bardzo fajna pozycja, z
dystansem i bez wychwalania.
https://i.redd.it/h7nt4keyd7oy.jpg ;)
:-)
A ta druga cegiełka to... no, konkret widzę :-)
Post by Borys Pogoreło
Jeszcze zapłaczesz nad tym językiem. Zacznij od razu uczyć się Typescriptu
- prosta rzecz, a przynajmniej mocno ograniczysz problemy wynikające z
niejawnych konwersji typów.
Dlatego debuger jest mi tak bardzo potrzebny, wtedy wszystko widzę jak na
dłoni.
A propos TypeScripta, na czym polega jego użycie? To się potem jakoś
przekompilowuje do JS czy przeglądarki go też kumają? No i na jakim etapie
jest kontrola typów?
--
pozdrawiam
Roman Tyczka
Cezary Tomczyk
2018-08-05 11:33:10 UTC
Permalink
On 04/08/2018 23:42, Roman Tyczka wrote:
[...]
Post by Roman Tyczka
A propos TypeScripta, na czym polega jego użycie? To się potem jakoś
przekompilowuje do JS czy przeglądarki go też kumają? No i na jakim etapie
jest kontrola typów?
TypeScript tak naprawdę transpiluje się do ES5/ES6/ES6. Niemniej jednak
z własnego doświadczenia mogę napisać, że na dzień dzisiejszy wszystkie
projekty rozpoczynam w TypeScripcie.

Co najmniej kilka powodów:

* Pilnuje typów danych. To powoduje, że wiem jakiego typu danych się
spodziewam. Oczywiście, to działa tylko na etapie pisania kodu w
edytorze, bo jak napiszę:

example(status: boolean): void {
this.status = status;
}

a REST API zwróci null to taka wartość będzie zapisana pod this.status.

* Znacznie lepsze możliwości refactoringu. Zmiana nazwy metody czy pliku
powoduje zmiany w całym kodzie.

* Definicje: interface, enum, return type, public, private, static, itd.

No i ważna rzecz: możesz mieszać swobodnie TypeScript i JavaScript!

Jeszcze 1 rok temu byłem stosunkowo sceptycznie nastawiony do
TypeScriptu, ale dziś polecam go każdemu. Spróbuj, sam ocenisz po jakimś
czasie.
--
Cezary Tomczyk
http://www.ctomczyk.pl/
https://www.aslint.org/
Borys Pogoreło
2018-08-05 12:59:59 UTC
Permalink
Post by Roman Tyczka
A propos TypeScripta, na czym polega jego użycie? To się potem jakoś
przekompilowuje do JS czy przeglądarki go też kumają?
Tak, musisz go przekształcić do standardowego JS. I z tym niestety musisz
się pogodzić - jakiekolwiek wyjście poza ramy "standardowego" JS oznacza
włączenie osobnego procesu transpilacji. Nieważne czy to będzie
TypeScript/CoffeScript, czy też cały framework typu React czy choćby użycie
kodu ES6 - czeka Cię nauka gulp / webpack / rollup (a do tego npm / yarn +
babel).

Co do samego TS - są metody na użycie go bezpośrednio w przeglądarce, ale
to bardziej w celu ułatwienia pisania i testowania kodu, niż użycia na
produkcji.
--
Borys Pogoreło
borys(#)leszno,edu,pl
Roman Tyczka
2018-08-05 21:11:07 UTC
Permalink
Post by Borys Pogoreło
włączenie osobnego procesu transpilacji. Nieważne czy to będzie
TypeScript/CoffeScript, czy też cały framework typu React czy choćby użycie
kodu ES6 - czeka Cię nauka gulp / webpack / rollup (a do tego npm / yarn +
babel).
Poczytałem o tym... włosy stają dębą... to jest tak pokręcone i
przekombinowane, że podziwiam tych, co w tym się sprawnie poruszają.

Już sama idea całego procesu jest kuriozalna z punktu widzenia
"klasycznego" programowania. Piszę w nieistniejącym języku, likwidującym
wady JS czyli w TypeSripcie, potem konwertuję to do JS, a potem tegoż JS
konwertuję do ...ups... także JS ale starego, bo nie wszystkie przeglądarki
kumają nowe wersje. Jednocześnie używam podobnych patentów przy CSS. A żeby
jeszcze móc odnaleźć błąd występujący w środowisku produkcyjnym (w starym
JS lub CSS!) muszę sobie zmapować mój kod w TS na JS za pomocą Source Maps!
Ponadto całe środowisko pracy i wszystkie narzędzia opierają się o NodeJS,
bo ...nie wiem czemu. I każde z narzędzi ma inną konfigurację zapisaną w
plikach JSONowych w dziesiątkach katalogów.
Oczywiście każde narzędzie ma kilka odpowiedników z rzeszą zwolenników i
każdy developer używa innego zestawu narzędzi, z innymi parametrami, innymi
zachowaniami, innymi wadami i zaletami. Ufff...

To wszystko brzmi jak sen wariata i ogarnięcie wymaga pewnej formy autyzmu
:-)
Na razie goły VSCode i klasyczny JS mi wystarczy, nie mam dodatkowego życia
na rozkminienie tego wszystkiego :-(
--
pozdrawiam
Roman Tyczka
Borys Pogoreło
2018-08-08 20:19:02 UTC
Permalink
Post by Roman Tyczka
Post by Borys Pogoreło
włączenie osobnego procesu transpilacji. Nieważne czy to będzie
TypeScript/CoffeScript, czy też cały framework typu React czy choćby użycie
kodu ES6 - czeka Cię nauka gulp / webpack / rollup (a do tego npm / yarn +
babel).
Poczytałem o tym... włosy stają dębą... to jest tak pokręcone i
przekombinowane, że podziwiam tych, co w tym się sprawnie poruszają.
Polecę klasykiem:
https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f
nic się nie zestarzało w tym tekście ;)
Post by Roman Tyczka
To wszystko brzmi jak sen wariata i ogarnięcie wymaga pewnej formy autyzmu
:-)
Tak, świat JS dokładnie tak wygląda. Musisz nabyć odporności i przestać
myśleć o tym całym bajzlu dziejącym się pod spodem. I mieć mocne CPU, by
proces transpilacji nie przeszkadzał aż tak bardzo.

A później się okazuje, że kodu będą używać w korpo na IE11 i załamujesz
się.
--
Borys Pogoreło
borys(#)leszno,edu,pl
Loading...