Big update to prettier-extension-monkeyc

Ok, great. That is the problem I found. And yes, it doesn't break anything, its just noise. I should have a fix shortly.

v2.0.11 is now posted at https://marketplace.visualstudio.com/items?itemName=markw65.prettier-extension-monkeyc, and should fix both your issues.

It also turns Toybox references into clickable links to the documentation, and fixes various other minor bugs.

The warnings are gone

The toybox links work partially. It seems to work for using and import and extends, but not always when it's used in code. For example these don't work:

Actually I was thinking about this and maybe we would want to do the exact opposite :)

I think it'll be better to change every line that you remove to an empty line. The reason is that that way the line numbers in the original and the optimized code remain the same, and that is very important, especially because we only save the source code in git, and when a month later there's an error in ERA Viewer then we won't be able to find anything if you removed lines...

flocsy🤠 said:

I think it'll be better to change every line that you remove to an empty line

Thats actually what I'd like to do ideally. But I'm relying on prettier (via my prettier plugin) to output the code, and it has its own ideas on how to format the results. Even if you've formatted the original code with prettier, the output will still change because of line length differences (eg because Graphics.COLOR_BLACK becomes 0 as Toybox.Graphics.ColorValue).

So I'd need to write a whole new formatter from scratch (I based my AST on estree, which is what the javascript prettier printer uses, so that 95% of the printing is handled by the bulitin javascript formatter). Its definitely something I'm thinking about, but not very high on my priorities right now.

A partial solution to your ERA Viewer problem would be to create an export-for-release task, and set its "outputPath" property to "releases" (for example). Then when you run it, all the generated files will go to "releases", rather than "bin/optimized", and you could then commit the optimized source once for each release.

flocsy🤠 said:

AppBase.initialize(); // doesn't work

This looks like a bug. It's not injecting the name of the superclass into the classes name space.

msg.setPayload(data); // this doesn't work

b.foo(); // this doesn't work

This is currently a feature. I'm not doing any type analysis, so I don't know that msg is an Ant.Message, so I don't know what setPayload refers to. I've considered adding a "Trust type declarations" option, which would help in the second case (once you fix the typo), but not the first (local variables can't have type declarations). This is also why you can't rename class variables and methods, but you can rename Module variables and methods, for example.

I am thinking about writing my own type checker, partly to solve this issue, but mostly because Garmin's is so bad...

local variables can have type as well:

class Foo {
 function bar() {}
}
function foo (a as Foo) {
 var b = new Foo() as Foo;
 var c as Foo;
 a.bar();
 c = new Foo();
 b.bar();
 c.bar();
 var d = new Foo();
 // d is not a type with type, so it can change:
 d = "String";
}

Regarding: WatchUi.requestUpdate();
Can this be because WatchUI is not imported or used? (I mean no: using Toybox.WatchUI). Though it's interesting how this even compiles then, but it does work :)

flocsy🤠 said:

local variables can have type as well

Actually, they can't. Or rather, they *have* types, but they can't be declared as being constrained to a particular type (the way that global, module, or class variables can).

var b = new Foo() as Foo;

This is just redundantly casting new Foo() to type Foo. You can assign anything you like to b on the next line. Yes, Garmin's type checker knows that b is of type Foo, and propagates that information (with or without the "as Foo") to later uses. But unless and until I also implement a similar type checker, I won't know what type b is at later points in the program.

var c as Foo;

ERROR: <device>: foo.mc:6: Invalid explicit typing of a local variable. Local variable types are inferred.

That pretty much says it all...

Can this be because WatchUI is not imported or used?

Maybe... import and using apply globally (ie across all files). They're runtime constructs, so as long as you import WatchUI in one file, its available in all of them (much like "var myGlobal;" is available across all files). In fact, using/import is *very* similar to var WatchUI = $.Toybox.WatchUI;

But my analysis should work the same way; so if you *do* have a using/import elsewhere in your project, it should still know what WatchUI is referring to (quickly checking that here seems to confirm that it works).