Btw. It was also #ReleaseSunday yesterday and as a direct & immediate result from a good criticism received via the community survey, I've updated all 350+ code snippets in 275+ source files/docs of all 190 https://thi.ng/umbrella libraries. Each snippet now includes imports for all functions/constants used, incl. those from other packages (if there are)... The updated docs have also been published on https://docs.thi.ng/. Hope that helps! If you do run into any mistakes & omissions, please get in touch! 🙏
Obviously, this doesn't fix other issues with the docs, but many of them are the result of other fundamental issues with TypeDoc & TypeScript's language server (e.g. treating arrow functions and/or functions annotated with type aliases as 3rd class citizens). I do not have the bandwidth to re-organize a massive project like this around the quirks/bugs of 3rd party infrastructure, but I'm always open to suggestions for how the situ can be improved... Many times I've been pondering and even starting work on a custom doc generator (incl. a ton more metadata, diagrams, cross-references, links to related functions [in other packages]), but I just cannot justify working on this at this stage...
Admittedly, I have never written a line of #typescript in my life. But between reading this by @rem and my CoffeeScript scars still aching when it's damp outside, I am very hesitant to give it a go.
Especially the part where you can just publish your TypeScript package without transpilation, and they handle #NodeJS /NPM compatibility is pretty big for IMO.
Backbone is an older JavaScript library these days, but is still an excellent base object model for more complex applications. However, it hasn't aged well.
Spina wraps Backbone, melding the best of Backbone and modern JavaScript development, and is TypeScript-first, helping it remain useful in modern codebases.
The immediate benefit here is now that all plugins used in a shared config are actually imported modules, so any host package that depends on the shared config, automatically has the right plugins. No more "multiple versions of an eslint plugin installed" problems.
I may have got a bit carried away writing a blog post presenting both a really practical way with a nice developer experience of handling asynchronous operations that might fail in TypeScript... and a "write your own monad in TypeScript" tutorial.
If you're interested in #FunctionalProgramming, #typescript, or both - please share. I think the techniques in this post can really make writing TS a lot more enjoyable, and the results more reliable.
Writing some #TypeScript for a project and… meh. It feels like JavaScript turned Java without the stdlib. I’m sure I’d get better / used to it given some time, but the vibe isn’t there for me. Fast feedback loop > strict typing any day IMHO, but to each their own.
Extensive use of inferred types, especially nested complex objects, is bad #typescript / #typesInJs for at least two reasons:
Inferring the types from the implementation rather than making a commitment to a concise and explicit type makes for a needless complex and unclear API-contract – increasing coupling and possible breakage