feature request: allow to spedify type checking level in the monkey.jungle file

I have an opinion on this, but I'm not going to expand on that here :) irc is more my thing. I'm in favor as well for this thing, because I think it is a missing feature that makes life easier for all.

Having said all that, I already voted for this idea and I'm curious to see what happens. Given that there's bugs (not feature requests) which are multiple years old and still haven't been fixed (and/or which keep coming back), I won't hold my breath.

"Actually, they have the right options already:

* Build project

...

* Build project for device"

Yeah, the names of those commands are suggestive but I'm not sure if their current intended use cases fit with what you're suggesting.

"Build Current Project" builds the PRG in the correct folder for the standard Run command to find it. "Build for Device" is more like "Export PRG" (you're prompted for an output folder) -- it's intended for sideloading afaik.

"the vscode plugin isn't an integral part of the buildtools. Although I feel you keep circling that thought."

That's your opinion, but clearly Garmin's intent is for people to prefer the VS Code plugin as opposed to the command line. Some of the new developers who post questions on these boards are often clearly not devs in their day jobs.

I mean in my day job as a dev the command line is king, but obviously the opposite is the case here. And it feels intentional. I'm not saying I like, but there's a lot of things about CIQ that I don't like. There's bugs and/or design decisions dating back 5+ years which have real impact on things like memory usage and app UX will never get resolved, so to me stuff like this is pretty far down the list.

> Well the default could be in monkey.jungle, but ofc it would always need to be overridden from the command line (and the Eclipse build dialog and/or VS Code build command "quick pick list"), since you want to be able to select a device on demand. Of course when the VS Code plugin exports an IQ field it needs to build for all devices in the manifest, so it def needs to be a command line option.

Actually, they have the right options already:

* Build project

Build the project with the defaults found in monkey.jungle, if there aren't any defaults, query the user or be smart about sane defaults. Pick the first device from the manifest to build the tool, limit typechecking, pick the highest possible API level (or lowest), and use the standard monkey.jungle file (obviously that can't be configured in the monkey.jungle file).

* Build project for device

Start a wizard with a set of options that default to the monkey.jungle file but override where needed

There are probably some other things you can do, but you would need to issue CLI options from a GUI in a non-intrusive way, which would make the amount of clicks unbearable.

> But then again, you can actually do this in the VS Code plugin options (at the user, workspace or folder level). Just so happens that won't help anyone who uses the command line :/

CLI already needs to take care of things, *BUT* by placing things in the monkey.jungle file it would make our live a lot easier because we have to use less options to buildtools. So we benefit from putting things in monkey.jungle

I actually think this issue is more of an epic, than a single change.

RFC: Place device in monkey.jungle

RFC: Place typecheck in monkey.jungle

RFC: Place API version in monkey.jungle

RFC: Place build warns in monkey.jungle

And than a bunch of RFC's to alter the vscode plugin to be able to deal with these changes.

> This may also be a limitation related to Garmin wanting to put config in the standard VS Code plugin settings, as opposed to its own proprietary file, like monkey.jungle.

Open source that plugin and let users tweak the hell out of it. Just make sure that the buildtools are nice to use. You can also build your own extension and publish that...  the vscode plugin isn't an integral part of the buildtools. Although I feel you keep circling that thought.

Maybe a nice compromise would be to provide a command line tool which would grab settings from the VS Code user/workspace/project/folder settings and launch the compiler as the plugin would. Idk if that's feasible, and ofc the major problem is that it would still tie you to VS Code.