vuex-typings VS bagel

Not a long time ago it was practically not possible to create good typings for vuex because of / convention used in namespaced modules. Typescript 4.1 introduced Template Literal Types which can be used to properly implement such behavior. I took advantage of this feature and created set of strong type definitions for vuex 4: https://github.com/kadet1090/vuex-typings.

This is a very similar philosophy to the MobX library (normally paired with React), and also to the programming language I'm building: https://github.com/brundonsmith/bagel

I’m really strongly rooting for Deno. I’m even implementing my current passion-project on it (https://github.com/brundonsmith/bagel). But I have a couple of significant (but solvable!) criticisms, if anybody on the team is here.

1) The documentation for the standard APIs is extremely wanting. The main, and weirdest, problem is that it seems almost impossible for search engines to index (or at least DDG). I can search for very very specific things, and still get kicked to the home page and have to manually navigate to the part I’m looking for (and the navigation is also pretty difficult; I often can’t find the thing at all and have to rely completely on editor hover-overs for documentation). It can also be confusing- some things like certain standard APIs appear to have multiple conflicting reference-manuals? And it can be hard to know which one is current or correct. Even getting past all the obfuscation, the docs are just ok. They often leave out deeper details (this last part is less of a problem and more understandable, this being a young project).

2) The VSCode extension still needs work. It’s usable, and better than nothing, and it’s better than it used to be, but (ordered from most to least significant):

- When I open certain files - usually bundles or something; maybe files outside of the project directory? - the language server crashes over and over and over, each time popping the terminal back up to show the output and distracting from what I’m trying to look at. This doesn’t happen with my normal, in-project, Deno files at least.

- It doesn’t have auto-import as you’re typing; you can auto-import by clicking the lightbulb, so I assume it’s a relatively short hop to plug that in

- It chokes on absolute import-paths in Windows. Thinks they’re malformed remote URLs

- It has caching issues sometimes. I’ll change some type in one file and other files won’t get the updated type until I close and re-open them, or sometimes the whole editor. This is uncommon so it’s not a huge deal.

I list these criticisms because I want to see Deno succeed. Switching from using TypeScript on Node (with the build steps/configuration, ad-hoc testing and linting, and Node’s pathological legacy APIs) to Deno was a huge quality of life improvement, even with all these problems. Brought to its full potential, I think Deno could be a revolution.