Big update to prettier-extension-monkeyc

markw65 said:

you almost certainly want @markw65/monkeyc-optimizer to be in devDependencies

There's nothing to publish as I have no JS code in my Monkey C projects, but I'll change this, thanks.

The sole purpose of package.json is to be committed along with package-lock.json for build reproducibility, just as you suggested in this thread a while ago.

As we are talking about local optimizer and searching for workspace root (aka location of "code-workspace" file), I ask another question. According to https://github.com/markw65/prettier-extension-monkeyc/blob/main/src/custom-build.ts#L60-L65 local optimizer will be used only if it is installed in project directory. I have VS Code workspace with multiple Monkey C projects in subdirectories, and I'd like to have single "node_modules" with optimzer and single package.json/package-lock.json in workspace root to install/update optimizer for all projects at once instead of maintaining each project independently. I tried to learn and use NPM workspaces, but it didn't work. Is there a way to achieve this now, or only "getMCFunction" modification will allow this?

9811827 said:

I have VS Code workspace with multiple Monkey C projects in subdirectories, and I'd like to have single "node_modules" with optimzer and single package.json/package-lock.json

So is this a single git repo, with multiple projects that all get released at the same time? I guess they don't all have to be released at the same time- but you do have to synchronize the package.json and package-lock.json with each project's release.

A solution would be to add a monkeyCOptimizerPath setting in VSCode, which could be set once in your code-workspace (with relative paths being relative to the code-workspace file, I guess). It would default to the project directory.

I could also just search upwards from the project directory, looking for a node_modules directory, or restrict it to only looking if it finds a code-workspace file that refers to the project directory...

markw65 said:

with relative paths being relative to the code-workspace file, I guess

Turns out you can't actually do that - see discussion in https://github.com/microsoft/vscode/issues/50372

We could still have the monkeyCOptimizerPath setting, but if you set it in a code-workspace file, you'd probably want to pick one of the sub-projects, and do

  monkeyCOptimizerPath: "${workspaceFolder:mySubProject}/../node_modules"

because ${workspaceFolder} moves around, but ${workspaceFolder:mySubProject} will always be mySubProject's folder.

Yes, it is a single repo with single workspace with multiple projects, that I release independently.

My current scheme is the following: when I'm working on project A I update its code and local optimizer version (for A and all other projects for now). When I'm done, I release A and commit package.json in A, so I can return to this commit and have the same code and optimizer version. Then I decide to work on project B I do B's stuff and use more or less latest optimizer version from the very beginning of new development iteration (it was updated along with updates for project A) and test B's behavior with current optimizer version and release B with its package.json. Thus updating optimizer version for all other projects is safe. The reason I do that is to have latest available local optimizer version with useful bugfixes for every project at the any moment of time. It's easier for me to do updates this way to be sure everything is up to date without the need to remember about updating every specific project.

markw65 said:

Turns out you can't actually do that

I think, I hit this (or very similar) wall after Garmin's plugin update from 1.0.10 to 1.0.11. I was using "${workspaceFolder:RootWorkspaceNameWhereCodeWorkspaceFileResides}" variable for developer key path, but they changed code for build tasks launching, and variable substitution stopped working. I now use VS Code task with "runOn": "folderOpen" to directly update project's settings.json files. Perhaps, I'll do as you suggest when the option will be avaialbe, or will update this option with absolute path to "node_modules" in my task, if "${workspaceFolder:...}" wouldn't work.

Thank you.

Sorry, I was looking at doing something about this, and noticed a pretty serious issue with the config settings when running from the command line in this way.

Many of the boolean options default to true in the extension. This is declared in the prettier-extension-monkeyc/package.json file, and it's all taken care of by VSCode.

In some of those cases, I carefully wrote the code to do the same - treat a missing option as true, rather than false. But I've just noticed that in most cases I didn't bother. The correct defaults are set by vscode (and by my "driver" wrapper than I use for tests), so I didn't really need to care about unset values - they were always explicitly set.

But if you run from the command line, those unset options will mostly default to false - so you'll probably get different results.

I'm going to try to fix it so there's a single point of truth (matching the current defaults for the extension). But meanwhile, don't rely too much on the command line tools unless you explicitly set all the config options.

I'll keep this in mind, thanks.

I would have 3 questions, would you be so kind to answer them:

1) will enums be optimised away to const values?

2) when a class e.g. does only contain inline functions will it be removed? the class is actually worthless if all functions in it are inlined somewhere else.

3) when I enable post build optimisation will ERA logs be messed up regarding code lines?

Michael said:

1) will enums be optimised away to const values?

Yes, although Garmin's compiler now does the same thing (it didn't when I first wrote the optimizer).

Michael said:

2) when a class e.g. does only contain inline functions will it be removed?

Currently not, but provably unused functions will be removed from the class. This is something I plan to do, but right now most of my time is being spent on other projects, so it might be a while

Michael said:

3) when I enable post build optimisation will ERA logs be messed up regarding code lines?

The post build optimizer should not mess up ERA logs, because it carefully rewrites all the debug location info. But the logs will refer to locations in the optimized source, not the original source, because there's currently no way to run the post build optimizer without also running the source to source optimizer (at least, from the extension - if you set things up to run the optimizer from the command line you could do that).