Echo JS 0.11.0

Definitely a nice to see feature... should probably enable by default for repositories with a package.json, like the package security/staleness checks.

Maybe my biggest niggle is that the styles' structure is in a mirrored tree instead of relevant CSS in/beside the component being styled.  Beyond this, the first instruction includes a css-in-js library, and mui contains another still.

This also covers way too much for a single article.  Realistically this could be several articles each covering a smaller piece and actually explaining the walls of code adding them a bit at a time.

Appreciate the inclusion of a plain JS example at the bottom.  Thankfully most browsers are green, continuously updated now, so the relatively new feature is available in anything current.

https://caniuse.com/?search=fromEntries

TLDR Url: https://github.com/mocks-server/main/tree/master/packages/config

Would be useful if you're writing configurable modules that will be used by other projects.

Aside: Wouldn't use this for applications/services as I tend to prefer environment variables, and load ~/.env with find-up directory tree searching from cwd.  .env for local use, defaults for local dev and environment injection on deployed servers.

Surprised this isn't using shadow dom for display, but cool all the same.

Many of these are arguable as the hinting system from typescript in modern editors (vs code, jetbrains, etc.) are able to determine return types, just as an example.  Of course this can be argued of linting generally speaking, so it's okay as options.

My biggest niggle with TS lately, is that tsc and deno have different import rules... for deno, you must use the extension, for tsc you must not, and I really wish tsc could be changed via an option to match the deno behavior, which I feel is more correct.  I think being able to share modules between the node/esbuild ecosystem and deno is going to become ever more important in the next couple years... especially if you can just share the ts source directly instead of built js modules with separate definitions.

Personally, I tend to prefer a feature oriented structure... where each feature is where directories are separated, and subdirectories created as necessary.

Each feature containing it's own context/state, components, tests and data fetching...  this can be registered with core routing and used in concert with more generalized components/wrappers.  It also tends to make it easier to break down into more of a micro-ui pattern if needed.

You can use redux-micro-frontend for state management in concert with exposing React and your UI component library of choice as global patterns from the start.  Again, easier to break things up later.

Just my own $.02

Not to be pedantic, but this isn't an implementation, it's a usage demonstration... an implementation would be a shim/shiv that adds it to String.prototype if it isn't present.

This is closer to where I'm coming from... when referencing articles, or interfaces, TS has pretty much become the more ubiquitous standard.  I'm fine with plain JS, but TS makes things a bit more clear in typical use... especially when explaining certain interfaces and libraries to make return types clear, etc.

Wonder if something like this could work with Microsoft's new Windows Terminal or Tabby.