If any "testers" have noticed, there are few updated builds. There is not really much of change in LSP itself actually. I'm trying to get VSCode for Web to work ā at least with CORS proxy (see below). But if you see message about a "new version" (that does nothing new), it's because it hard to test VSCode for Web Extensions, so just been pushing update to the "web" side of the code.
VSCode for Web support...
What is it?
VSCode for Web is a version that runs in web browser, but support some extensions as desktop. You can try it at https://vscode.dev. VSCode for Web is also used on GitHub when you type . whin a repo and that brings the repo up. Or, on desktop, normal VSCode can launch it via code serve-web.
WIP for Router LSP
I have started the "plumbing" need to build extension for VSCode for Web. So while RouterOS LSP loads in Web edition, there are still some TS/JS/ESM/CJS "packaging" issues to work out. These are fixable. But the larger issue with running RouterOS LSP in VSCode for Web is CORS.
The effect of CORS is that the RouterOS LSP (and TikBook cannot make any calls to RouterOS's REST API when running in VSCode for Web. The REST calls are absolutely needed LSP, and also if you want to "run cells" in TikBook (which can read/write RouterOS TikBook without REST). There is no client-side workaround to it, the server must return the right headers in OPTIONS preflight request ā it just how it works. And RouterOS does not send the right things for CORS support in browser for REST API.
Using CORS proxy as workaround
I have an open feature request for CORS support in REST API for "some time", as it blocks the modern SPA approach. But one "workaround" is to use a "CORS Proxy" ā which really just another web server that sits between VSCode for Web clients and RouterOS, that "fakes" the need response to CORS request from browser. I've tried a few approach to CORS proxies as /container before like NGNIX, Traefik, and recently Caddy:
X.509 client certs for REST API authentication be ideal...
The "original" approach using NGNIX has ability to use a client certificate for authentication ā instead of just passing username/password through proxy to RouterOS. This is useful approach since storing credentials in VSCode configuration is far from ideal. However, add even more complexity to CORS since now there is cert management task too - also something not so simple.
But eventually I'd like the RouterOS LSP to have the ability to "Use X.509 Client Authentication" as alternative to asking for username/password. I still need to try X.509 with Caddy, but if that work I'll probably publish a /container pre-configured. Now the container still needs a username/password to proxy, but having the RouterOS password on itself is less problematic than random browsers.
Ironic side note...
In discussion about the new forum complaints about "syntax coloring" in RouterOS script on the forum came up quick ā so that was good to know that people do care about color highlight. But irony comes when my post about "Caddy as CORS proxy" was sent to "pending approval" by new forum software & now MT forum admin now dealing with CORS to enable coloring in this forum - just can't make this up:
Which is different CORS problem than here. I suspect the problem on forum is that Discourse comes with a restricted CORS setting out-of-box. But enabling languages in highlight.js library used by forum software, it likely gets the "extra languages" like RouterOS by downloading them from GitHub/NPM/CDN ā but since that is a different domain the "forum.mikrotk.com", CORS on your browser blocks the download for highlight.js's version of RouterOS syntax. Which is actually a different CORS problem but point is #CORSucks