There are currently two main module formats in the JavaScript ecosystem: ECMAScript Modules (ESM) and CommonJS (CJS). CJS was first, but ESM is now the JavaScript standard and is the future. The main difference between the two is how they import files.
Npm is a package manager for JavaScript projects. What this means is that it enables easy installation of packages (published to the public registry, https://www.npmjs.com, or private registries) while also installing nested dependencies between packages. I received a bunch of questions about npm, and here are the answers! Note that I haven't looked at implementation details or any specs on how npm works, these answers are merely based on my observations after nearly a decade of using npm.
c8 is my preferred package for calculating code coverage in Node.js testing and it is also apparently used by web-test-runner. However, c8 supports a lot more ignore comments then they document. Below I've listed all the supported comments from my own personal testing and some other notes about ignoring lines for code coverage.
If you look at the import.meta docs on MDN you'll notice that it says:
The spec doesn't specify any properties to be defined on it, but hosts usually implement the following properties: [url, resolve]
So what is actually in there? MDN is correct in saying url and resolve are usually (always) implemented, but each run-time also sticks some other stuff in there. From my own testing, below are the values that exist for each major runtime.
Node.js now has a built-in test runner, which I've now tried, and it's fantastic! However, it can't be used for frontend testing, or browser testing, obviously. While web-test-runner is the best (imo) test runner for frontend tests, having different runners requires you to learn different libraries and use different imports for each even when doing dead simple environment-agnostic unit tests. In this post I'll talk about how I've unified the experience, and the path that lead to being able to do that.
element-vir is a package for defining and rendering custom HTML web components. It wraps Lit and aims to dramatically reduce the number of mistakes devs can easily make. This post will talk about how rendering within element-vir works.
Web Components are reusable, native chunks of shared HTML, CSS, and JavaScript. They are the way of reusing HTML and defining tightly-scoped and decoupled blocks of HTML with dedicated styles (CSS) and logic (JavaScript). How do you use them? This post is a high level introductory answer to that question.
This is intended to be a very basic high level overview of GraphQL, explained to a developer that already understands the basics of REST API design. This is not a deep dive into all GraphQL's features or a GraphQL pros/cons list. Also, while GraphQL is backend language agnostic, this guide will be mentioning JavaScript implementations (since that's what I work with).
If you're using TypeScript and ESLint in VS Code, wip files or legacy files can quickly explode into a sea of red squiggles, making it hard to know where to start or track what's going on.
I like to hone in on type errors first, since they're typically more critical (as in, type errors will often completely crash your code). I keep those as scary red squiggles and tone ESLint down a bit by changing all its squiggles to just (orange) warnings.
This is easy to do with a quick edit to your user settings JSON file (accessed via the >Preferences: Open User Settings (JSON) command in VS Code):
"eslint.rules.customizations": [
{ "rule": "*", "severity": "warn" },
]
Use {@link VarName} in JSDoc comments when referencing variables or types to get:
I assume that all the features in VS Code are driven by the TypeScript Language Server and thus are applicable to any editor that utilizes that same language server.