We can’t really do anything about this can we? @astrochili has already created an integration. Why reinvent the wheel just to put our name on it?
This is something we might be able to assist with. If there are things we can do in Defold to make it easier to work with Defold projects in VSCode, then yes, we can maybe do something there.
As mentioned above, this is something we can do in the official documentation etc.
I am not an expert in how any of this works but the one thing that springs to my mind would be if there was a way to automate things so it wasn’t a requirement for guides/extensions to manually be updated. If I’m not wrong, the .defold_api folder is just lua files with function stubs and doc comments. Guessing astrochili has created/updated these manually to reflect the actual engine API. In github it seems to have last been updated 6 months ago, so may not even be accurate.
If Defold could make some offical documentation that would be great actually, but another cool thing would be if these could somehow be auto generated from the actual code, so they are always updated. Sort of how I’m assuming the API docs are done. I would not be surprised if having these files provides the basic editor functionality to other editors as well so unless there is a better way to get this directly from the engine in external editors, having a way to generate these files from Defold, using the current version of the engine would be pretty awesome.
To support and provide a new level of interaction with the VS Code extension.
I am not an expert on VS Code extensions and in-between process interaction, but I would assume you would need a different kind of integration with VS Code. Perhaps opening a TCP socket to send commands from VS Code to Defold, and API structure (including defold extensions) from Defold to VS Code. As well as console output.
I understand that such work is not so important compared to the rest of the engine development. Maybe some Defold partners would be willing to help with that. I can only imagine what a great level of expertise it requires in both VS Code extension development and Defold Editor/Clojure development.
Of course it would be great if such a person would come from the community but I think it’s a too complex task.
What would be the purpose of these commands? To build and run the project?
I think what we can do is open up the editor such that it is possible to interact with the editor from the outside, for instance to build and run the opened Defold project. This could be done using HTTP requests in the same way as the Defold editor communicates with a running Defold engine. As long as it is simple and generic then I’m sure it can be used and implemented in VSCode or other external editors without much difficulty.
I am a VSCode user, and the above is as of now the main blocker for me returning to the Defold code editor. There may be more features I’m missing, but because I can’t move it to a separate window I haven’t used the Defold code editor since 2018 
I have previously felt along the same lines as OP, however I do find the arguments stating that Defold should contain everything needed to get started quite convincing. One of the strengths of Defold is how easy it is to install. As a relatively experienced Defold user it’s not relevant to me anymore, but I shouldn’t forget that this was actually one of the reasons I picked Defold in the first place.
It’s worth noting that the latest sumneko-lua extension for vscode supports defold-api out of the box,. I’m not sure how updated it is or the frequency of the updates. That is the api folder that it was mentioned in previous posts. It’s not as comprehensive as the template from @astrochili though.
I started using vscode recently, but only as a code editor on a project that is mostly code (script) based. When doing visual layout the editor is my go to place. Switching app adds too much friction for my taste.
I still do all my build and debug from the defold editor itself .
Just put this on your settings.json file, then you will not need to add Defold api folder.:
"Lua.workspace.library": [
"${3rd}/Defold/library"
]
Perhaps this should be added to readme.
I tried Luanalysis (only available in IntelliJ IDEA), compared it with VS Code and so far Luanalysis beats EmmyLua for me. It does a great job at type checking. Exactly what I was looking for! I haven’t tried it in a real project though. With additional annotations you can have type safety even for messages. Yaay! 
The Github feature request mentions the “editor’s web server”. Is it already exists or will it be a new thing? It sounds like something that opens a lot of possibilities. Anyway… for starters, run a project from within an editor would be great!
We had a meeting about this topic yesterday. Some takeaways from the meeting:
Regarding missing features in the built-in code editor:
Great!
Few points about the existing solution. It works, but I agree that It’s hackish and not user-friendly to setup.
This is not a VSCode extension, but it would be better if it was. The problem is that I have no experience of integrating with the VSCode API and no desire to go deep into these js/web technologies at the moment. @thejustinwalsh, author of ts-defold, created an issue ‘Join Forces?’ where we exchanged some views on how this could be.
A real VSCode extension would make it easy to install in one click and get the settings integrated into VSCode, which is much more desirable than editing the sh-file top variables.
Right now this is only possible with bob because of known limitations. But after implementing some of the features mentioned above, it will be possible to run an editor build from VSCode.
The current proposal is to use local lua debugger, which works perfectly and is very functional thanks to the full integration into the VScode debugging environment (more functional than the built-in debugger in Defold Editor).
If we want to run the game from Defold Editor and continue debugging it in VSCode, we need to connect to mobdebug. But at the moment there is no great working integration mobdebug in VSCode as I know.
It’s true, I just copy the lua headers from defold-api-emmylua by @d954mas, thanks to him. Since I haven’t figured out how to run this thing without installing IDEA to generate headers from the public docs (but I didn’t try very hard), the template project has the same API version as the original repository - 1.3.3 at the moment. It’s defenitely a point which can be improved and automated.
Defold has more comfortable way to interact with libraries and built-ins files, wich are not available in VSCode. There is a hack way to get library headers in VSCode, but, again, it is done manually.
Right now there is no way to view or copy the built-in files outside of the editor. Only if attach all these files to the template, it’s possible I think, but will require more manual work to update the extension for each engine update.
I’ll be happy for any help, even if someone takes and rewrite everything, as long as the current working functionality is preserved. I mean, I don’t think it makes sense to create another extension with only one specific running function or only lua headers, otherwise those who need to debug with breakpoints or bundle and deploy a game on devices won’t be able to combine it all into one system.
Excellent write-up @astrochili ! Do you have these issues/feature requests collected on GitHub?
I really encourage others in the community to get involved in this project. We will do our part and open up the editor for integration in external tools. And perhaps we can also assist with some other things, such as API header generation in a format which VSCode can use.
Yes, now there are! 
Me neither))) I had IntelliJ installed but I couldn’t run the defold-api-emmylua, so I reinvented the wheel. You can grab annotations for v1.4.1 here. They might not work 100% in VS Code. For me Luanalysis is sooo much better than extensions in VS Code for Lua. Some things there are different than in EmmyLua though. Feel free to create an issue if something is not right. I can help with generating more stuff like that if anyone needs.
Thank you for it! It is detailed and good to work with!
Only a few minor issues that required custom code and custom types to be used for certain functions and messages. Not a big deal.
For annotations 3 msg.post functions with different parameters have to be “merged” into one element with different overloads, and “table” types are not intellisense friendly (i.e. [play_properties]).
As of now I have no idea if it’s possible to debug Lua with mobdebug in IntelliJ. I’m ok with debugging inside Defold editor.
My personal top request for debugging is not related to a code editor at all. An ability to see all instances at runtime and their go.properties while the game is running. It’s a HUGE asking, and not like I’m making any games anyway
Something more pragmatic would be to add custom expressions/variables and “Watch” them in a window, rather than typing every time. That’s only because I can’t or don’t know how to debug in IntelliJ.
My dream setup so far. + 2 helper modules generated from the API docs.
Thanks for Defold-Lua-Annotations, looks more updated than others.
According to the description, Luanalysis looks very good, but it’s for IDEA as I understand it.
To VS Code Users,
Improved Defold-Lua-Annotations for ‘table’ parameters and callback functions for better Intellisense and autocompletion. I tried with sumneko.lua plugin. For EmmyLua they should work too, but I haven’t tried it.
Have only just seen this thread and theres one thing I dont quite understand.
With a dual monitor setup, you can have one with Defold open, and another with VSCode open.
You can edit all you want from VSCode and run from Defold (as it will pickup you changes) or you can use the extension setup (I think I used a different one). Heck you can even call bob yourself, probably hook it up to Emacs or Sublime and run it however you want?
Yes, debugging and such can be more complicated, but Ive also used a number of Lua based remote debuggers that work fine, so there are options for your flavour of editing and debugging.
I personally believe the Defold Foundation needs to focus and design around a single tool suite, otherwise their resources will be spread too thin. And if people want something different, then please build something? Its all open source. I find this the most frustrating thing when I see people demanding features when not a single cent has been transacted, and theyve not made an attempt themselves to understand what they are asking, nor attempt to apply a solution of their own design.
I commend @astrochili and the Defold Foundation members for doing such a large amount of work for such little compensation - honestly, theres very few people in the world what would work like this, and be happy to then also take on demanding suggestions.
So… @ekt - you seem to want something like unity where you can select your editor of choice. If so, have a look at the editor codebase see how much work it might be, make a PR and help Defold provide a solution. I think thats a highly fair way to move forward. You could even engage others on the Defold forum, and build a team to create such a solution if your time and software skills are limited. Theres lots of good ways to go about this. Making a complaint thread… dunno I agree with that process.
Note: I think its important not to strain an open sourced project team like Defold. Ive recently seen many large open sourced project fall down and disappear purely from the weight of demand and growth in codebase maintenance. A bit of patience, with a bit of good contributions to source code really helps them.
hi @dlannan
I don’t know you but I respect you for your activity in the community so I want to answer you trying to clarify why I don’t think you interpreted my thoughts correctly. please also read the answer I gave to @britzl later in the thread.
no. that’s not what I’m asking. in fact the possibility to choose an editor is already there in preferences\code editor.
and there are already two different extensions thanks to @mikatuo and @astrochili. they’re not perfect (difficult debugging, slower build times) but they do what I want, I use them and I’m happy! thanks @mikatuo and @astrochili
Precisely because Defold is maintained by a small group of developers, I think they need to choose carefully which battles to fight.
My point is that as much as the Defold developers try, the Defold code editor it will always lag behind products like VSCode
My hope and suggestion was that the Defold developers would stop evolving the internal editor but would officially support the integration of an existing code editor of their choice.
Mine wasn’t a complaint but I was suggesting a change in strategy that in the long term would relieve them of work that I don’t consider core. I completely agree that an open source project can succumb to feature creep, in fact exactly for this reason I suggested reducing the effort in the code editor, and leaving it to others. because the (few) defold developers are better used for core stuff.
Having said all this, later in this thread there is a response from @britzl with the official position of the Defold team which I fully respect and for me this is a closed topic. I’m just sorry that you read it as a ‘whiny complaint thread’, that wasn’t my intent.
