I'm trying to get a Playdate/Lua development environment set up, and while it's all going fairly well, there's one last thing I'm struggling with: following local imports with "Go To Definition" or ctrl-click.
As a constrained example, I'll use the VSCode Playdate template project, as opening this directly with all the requisite plug-ins exhibits the same behaviour:
If I open the main.lua file, I can get auto completion on any of the CoreLibs objects, and ctrl-clicking anything in those method chains at least brings me to the stub file, and sometimes to an actual implementation depending on what's defined where.
However, ctrl-clicking on the "dvd" import, the class name dvd, or any of its methods doesn't take me to the dvd.lua file which is located in the same folder as main.lua, and while everything compiles and runs just fine, whatever I've done in my environment leaves VSCode incapable of finding any of the definitions within the workspace.
Since most things in the environment work, I feel like I'm missing something incredibly obvious, or overlooking some critical detail which I've also glaringly omitted from my question here.
Intellisense is provided by the Lua extension. If I type dvd: in main.lua it will autocomplete the functions on the dvd object correctly. However, trying to jump to the definition doesn't seem to work. I'm guessing that is just a limitation of the extension.
Yes, that closely aligns with what I'm seeing -- auto-complete works, go-to def doesn't -- except I can get "go-to definition" to work with functions from the PlaydateSDK, so there's clearly something about the configuration of the extension that at least permits that. I fully admit to not being a Lua dev traditionally, so I'm willing to try anyone's harebrained ideas about how to get around this.
Another data point I just tried out today: the Lua VSCode extension uses the Sumneko language server, they advertise "go-to definition" functionality as a core feature, and if I use require syntax on local files then "go-to definition" works more fluidly, but then I get an error when running in the simulator (and I assume the hardware too, I'm one of those folks waiting for theirs to ship so I can't confirm)
From that data point, a chain of questions:
Could this be a product of the non-standard import syntax used for Playdate applications?
If so, should I be engaging the folks on that project to try and get them to follow our import syntax, or should I be engaging the folks here to try and find workarounds for the syntax that serve both pdc and the Sumneko language server?
Personal context to take or leave freely as it adds absolutely nothing to the technical discussion:
I'm typically a C/C++ dev, and would happily work in C, I've gotten C projects working with full auto-completion, "go-to definition", etc. and it's great, it's arguably the most friendly C API I've ever encountered as well. However, I've got partners on my project that have expressed... we'll call it "resistance"... to working in C, and I totally get it, I'd like to support their preferences.
With smaller projects, not being able to use the intellisense to navigate isn't a killer, but it's the kind of workflow speed-bump that's going to transition from uncomfortable to painful really quickly as things get more complex, so I'm doing everything I can right now to resolve this issue to avoid forcing my team to use C.
Oh yes, I'm sure this is due to the way we use import (I had sort of forgotten about this). It would be amazing if the Lua extension folks would add support for following import paths for Playdate development.
"Go to definition" in local files works fine for me in VS Code.
The problem with dvd in the template project is that it's a "class" using the object orientation helper provided by the SDK.
That helper, let's say, doesn't exactly do things the typical Lua way. It works by assigning to the globals table _G directly as part of extends() (see line 80 in CoreLibs/object.lua).
This works fine at runtime, but is completely opaque to any static analysis -- we can't really expect the language extension to figure out that the line