Anyone here use Visual Studio Code? Thoughts?
I primarily use Kode Studio, which is a Visual Studio Code fork built for Kha, which I use for building Kha applications since it is the preferred method. I think the in-built NodeJS debugger is what keeps me using it, because it is very useful. I find Kha easier to use for that reason, over OpenFL, because of the native debugging tools.
With OpenFL, however, and the way you need to configure Visual Studio Code, requires extensive knowledge of the VSC extensions API and, while it would be useful to have a fully compatible extension for OpenFL development, would likely take time and effort.
I do still use HaxeDevelop for OpenFL simply because HaxeDevelop’s native OpenFL template contains auto-completion features I’m too used to having.
As a general-purpose code editor, VSC pretty much does everything you expect plus the extra debugging features that are otherwise unavailable on Linux. I suspect Linux fans particularly enjoy using VSC for that reason alone.
I gave it a spin but it looks like my HaXe OpenFL version was out of date so pretty much nothing worked with the HaXe plugin. Had to get some legacy stuff out the past couple of weeks but looking at upgrading today and giving it another shot.
Visual Studio Code was built by Electron and Node.js - it uses only for HTML5, CSS3 and JavaScript.
I suggest you about that if you don’t want to write haxe files and write just obly JavaScript with node.js
If you use Linux or MacOS than you need to copy from Visual Studio Code\resources\app to linux’s or macOS’ electron than you can work with Visual Studio Code well. If sometime features of Visual Studio Code like Node.js modules if it doesn’t work than you can work with Html5, CSS3 and JavaScript. Where is your problem? Enjoy and write your creativity!
I am using it exclusively now after switching between Atom & VSCode. After the newest release of vshaxe it’s a no-brainer to use it for Haxe development. For debugging Kode-Studio just uses this extension (https://marketplace.visualstudio.com/items?itemName=msjsdiag.debugger-for-chrome) and glues it together with the launch.json script in .vscode to work together with an Electron instance it launches.
Adding an extension which just scaffolds something for OpenFL would be easy (just have a look at the vshaxe extension) and the debugging stuff is hopefully done by the vshaxe guys.
For the new krohm stuff it obviously changed…
I have just begun to experiment with this the last few days, and although it’s a pain to set up, it seems to work smoothly and well, with a few caveats.
First off, setting it up with the Haxe Extension Pack is dead easy. Getting beyond that was a little more involved.
I’ll include a few pointers here in case it helps anyone else, because I found it hard to set up for OpenFl, in spite of the excellent documentation on the vshaxe wiki. Be sure to visit both the Configuration and the FrameWorks pages to get a feel for what’s going on.
For projects that are built with a simple build.hxml file, the symbol parsing and the code completion features work well as long as you add the build.hxml file to the haxe.displayConfigurations setting.
At a minimum, you’ll need to modify these settings:
“haxe.displayConfigurations”: [ // one or more configurations for the haxe completion server
[“build.hxml”] // build hxml file
],
“haxe.displayPort”: 6000 //this connects to the completion server
It took me a while to figure out how to get code completion, etc. for my OpenFL projects.
I found that the easiest was was create a fake build file at the root level of each project, and then reference that in the haxe.displayConfigurations.
haxelib run lime display > fakebuild.hxml
//e.g. haxelib run lime display html5 > fakebuild.hxml
This is only for code completion. I use the integrated terminal to build as normal. The “Problems” tab of the terminal is suitable for jumping to lines with errors. For my normal workflow, that’s all I need.
The framework documentation suggests that it’s preferable to dig down and add the hxml file for each target to the haxe.displayConfigurations (e.g. [“Export/flash/release/haxe/release.hxml”]). However, in my experience, this did not work at all until I modified my project.xml file to include this line:
<source path="/usr/local/lib/haxe/lib/openfl/4,8,1/externs/core/openfl" />
After that, code completion, etc. worked, but the build output included a bunch of warnings that were irrelevant to me. I also found not much value added by creating a run task. For me it was much easier to pop down to the terminal and build there.
Having said all of that, the syntax highlighting, rapid code completion, symbol browser, and integrated terminal make Visual Studio Code a compelling option for coding, and well worth the hassles of setting up. My hat’s off to the vshaxe crew for turning VSC into a very effective haxe coding solution!
1 Like
The problem here really is that OpenFL isn’t able to generate VSCode workspace files out of the box with openfl create. Flixel’s command line tools support this, making the overall process very smooth - flixel-templates includes display configurations, build tasks as well as debug configs:
In fact, for the most part, Flixel’s template files work just fine for OpenFL projects as well (I’ve used them succesfully for OpenFL 3 projects).
The only real issue is that recent OpenFL versions have changed the project layout a bit, and in the export directory, builds are now separated by release and debug. This means that the paths for the display configs need to be adjusted.
Setup will hopefully become a lot smoother on vshaxe’s side once / if it controls the build process (some discussion on that here). This requires some VSCode extension API features first though.
Another option is to set up your own tasks. My tasks.json file looks like this:
{
// See https://go.microsoft.com/fwlink/?LinkId=733558
// for the documentation about the tasks.json format
"version": "0.1.0",
"command": "openfl",
"isShellCommand": true,
"args": ["test"],
"showOutput": "always",
"echoCommand": true,
"tasks": [
{
"taskName": "android debug",
"args": ["android", "-debug"],
"suppressTaskName": true
},
{
"taskName": "android release",
"args": ["android"],
"suppressTaskName": true
},
{
"taskName": "flash debug",
"args": ["flash", "-debug"],
"suppressTaskName": true,
"isBuildCommand": true
},
{
"taskName": "flash release",
"args": ["flash"],
"suppressTaskName": true
},
{
"taskName": "html5 debug",
"args": ["html5", "-debug"],
"suppressTaskName": true
},
{
"taskName": "html5 release",
"args": ["html5"],
"suppressTaskName": true
},
{
"taskName": "ios debug",
"args": ["ios", "-debug"],
"suppressTaskName": true
},
{
"taskName": "ios release",
"args": ["ios"],
"suppressTaskName": true
},
{
"taskName": "neko debug",
"args": ["neko", "-debug"],
"suppressTaskName": true
},
{
"taskName": "neko release",
"args": ["neko"],
"suppressTaskName": true
}
]
}
"command": "openfl", "isShellCommand": true means that this will run the command openfl in the command line. "args": ["test"] means that it will always include the argument test. Then there’s an array defining possible arguments to add after test.
Next, I set a hotkey for "workbench.action.tasks.runTask". When I press the hotkey, it lists the options from the array I defined, and I can pick an option using the arrow keys or by typing a few characters.
Since I run flash debug the most, I set "isBuildCommand": true, which makes it run when I press ctrl+shift+B. (Actually I made a more convenient hotkey for it, but that’s beside the point.)
"suppressTaskName": true is there because otherwise, it would include the task name in the arguments. This means you could define tasks using only the "taskName" field, but the names wouldn’t be as pretty.