Jump to content

Debug Phaser ES6 + WebPack in WebStorm


Igor Georgiev
 Share

Recommended Posts

Hey guys, I have decided to start using webpack and ES6 with my games, I have managed to run a sample with 'npm start', however I am unable to debug it in WebStorm. 
I am using the example here: https://github.com/SvetoslavKuzmanov/phaser-game-boilerplate

This is my debug configuration in the image.

I would like to use npm directly from WebStorm and be able to debug my code with preview in the browser. Also I have heard that it is possible to have live editing set up, so my code changes will appear immediately in the browser.

Has anyone done that?

debug example.PNG

Link to comment
Share on other sites

2 hours ago, Igor Georgiev said:

Also I have heard that it is possible to have live editing set up, so my code changes will appear immediately in the browser.

Has anyone done that?

Yes, multiple times, and there are a few different ways to set it up, the easiest being to use livereload. Live reloading always requires two things, firstly, something needs to be watching changes (either changes to source, or, changes to build output) and firing events when changes occur and, secondly, something in your environment (in this case, the browser) needs to be listening and responding to changes. Usually a change response is to reload the page although reloading the CSS is also fairly trivial, in the case of your games reloading the page is the safer option.

Webpack comes (I think) with its own zero config live-reload-enabled browser, the tutorials at their site are fairly trivial to set up for a statically served app (unless you've bolted on multi-player or some other shenanigans your Phaser app will be wholly clientside). You'd just need to be able to run a script to start this, this is easiest if you have a dedicated terminal or CLI but, again, I think WebStorm includes one for your use.

If you're talking about 'hot module reloading', i.e. reloading only parts of your app when they change, then this is significantly more complex and with some (most) frameworks and setups it is impossible, I'd have thought that Phaser is in the impossible category but I'd be happy to be proved wrong, it's certainly a powerful development process.

I've no idea how or what you think you can debug in Webstorm, but, that setup page looks like it just specifies a node instance to use, as your code runs in the browser it doesn't need node (although your build pipeline almost certainly does, but why would you want to debug that? Unless you're developing it you dont need to debug it). There is an addition architectural thing here, you only debug in your runtime environment, which is your browser, not webstorm. You can statically analyse your source code but if you want to debug it, which, by definition, means that it is running, then that must happen whilst your code is executing i.e. in the browser.

Edit: I just checked out the boilerplate (on a side note, wowser, webpack makes simple things incredibly complex) and the npm start script is all you need, it starts the dev server which should be watching for changes, from their docs it also looks like it probably inserts the listening script explicitly so you'd just need to open your browser and you should be good to go with live changes.

Link to comment
Share on other sites

44 minutes ago, mattstyles said:

Yes, multiple times, and there are a few different ways to set it up, the easiest being to use livereload. Live reloading always requires two things, firstly, something needs to be watching changes (either changes to source, or, changes to build output) and firing events when changes occur and, secondly, something in your environment (in this case, the browser) needs to be listening and responding to changes. Usually a change response is to reload the page although reloading the CSS is also fairly trivial, in the case of your games reloading the page is the safer option.

Webpack comes (I think) with its own zero config live-reload-enabled browser, the tutorials at their site are fairly trivial to set up for a statically served app (unless you've bolted on multi-player or some other shenanigans your Phaser app will be wholly clientside). You'd just need to be able to run a script to start this, this is easiest if you have a dedicated terminal or CLI but, again, I think WebStorm includes one for your use.

If you're talking about 'hot module reloading', i.e. reloading only parts of your app when they change, then this is significantly more complex and with some (most) frameworks and setups it is impossible, I'd have thought that Phaser is in the impossible category but I'd be happy to be proved wrong, it's certainly a powerful development process.

I've no idea how or what you think you can debug in Webstorm, but, that setup page looks like it just specifies a node instance to use, as your code runs in the browser it doesn't need node (although your build pipeline almost certainly does, but why would you want to debug that? Unless you're developing it you dont need to debug it). There is an addition architectural thing here, you only debug in your runtime environment, which is your browser, not webstorm. You can statically analyse your source code but if you want to debug it, which, by definition, means that it is running, then that must happen whilst your code is executing i.e. in the browser.

Edit: I just checked out the boilerplate (on a side note, wowser, webpack makes simple things incredibly complex) and the npm start script is all you need, it starts the dev server which should be watching for changes, from their docs it also looks like it probably inserts the listening script explicitly so you'd just need to open your browser and you should be good to go with live changes.

Thank you for the extensive information on the topic :). I will try to figure out which approach is the best and try to implement it. I have never done it, so if something gets stuck, I will ask again. :)

Link to comment
Share on other sites

  • 2 weeks later...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...