DEV Community: James Garbutt

Migrating from chokidar 3.x to 4.x

James Garbutt — Wed, 18 Sep 2024 04:16:15 +0000

A big win recently in the e18e space is that chokidar published a new 4.x version!

This new version drops a whole bunch of dependencies and simplifies the internal logic greatly, leaning more on modern platform capabilities.

For those of you who don't know what chokidar is - it is a widely used file system watcher which provides an abstraction over the top of Node's own watch functions. More than likely, it is somewhere in your dependency tree already!

Dependency graph difference

In chokidar 3.x:

In chokidar 4.x:

Changes in 4.x

Most of the changes are internal and shouldn't affect how you use the library, but will improve performance a huge amount.

A few notable changes:

fsevents was dropped since Node itself handles cross-platform compatibility well these days
ES module support
Improved TypeScript types
Various performance improvements
Glob support removed

The one major change from this list that will affect users is the removal of globs.

Life without globs

In chokidar 3.x, it was possible to watch a glob. For example, we could watch src/*.ts and chokidar would expand the pattern internally to watch all TypeScript files inside src/.

In 4.x, this functionality has been removed since you can achieve the same with filters or an external glob library.

An example:



// chokidar v3
watch('src/*.ts');

// chokidar v4 (RegExp)
watch('src', {
  // any path whose end is not preceded by `.ts`
  ignored: /(?<!\.ts)$/
});

// chokidar v4 (ignore function)
watch('src', {
  ignored: (path, stats) =>
    stats?.isFile() &&
    !path.endsWith('.ts')
});

// chokidar v4 (glob)
// NOTE: this will not watch newly added files. It
// will only watch the initial set of files
import {glob} from 'tinyglobby';
watch(await glob(['src/*.ts']));

In most cases, you can probably avoid the need for a glob library and use a filter function or RegExp instead (which will also be much faster in many cases).

Feedback

If you upgrade and have any feedback or find any bugs, we'd love to hear from you via issues.

You can also catch many of us in the e18e discord working hard on migrating popular packages from 3.x to 4.x.

Cleaning & speeding up the JS ecosystem - Journey so far

James Garbutt — Tue, 03 Sep 2024 23:41:37 +0000

For some time now, I have been hard at work at increasing performance across the ecosystem. Usually through cleaning up aged dependency trees, reducing install footprints, and improving CPU/memory performance of commonly used dependencies.

This blog post is just my brief attempt at explaining some of the journey that lead to e18e and the ecosystem cleanup.

Thoughts on micro-utilities

Micro-utilities are a major contributor to the install size and, more, the dependency tree complexity of many projects.

Packages such as is-number and is-nan fit into this category.

Importantly, many of these packages do have a use in some situations but certainly not in the common use case.

Usually they can be replaced in these situations:

They were written in a time when equivalent native functionality didn't exist, but now does
They do more than what the consumer needs

Example: is-number

For example, is-number determines if a value is a number or a number-like string which is not NaN or +/-Infinity.

In some projects, this is a repeated piece of validation which may be better extracted into its own module or package.

However, in the common case, many consumers never needed the NaN and Infinity validation, or even to support number-like strings.

This opens up some possible improvements in various projects. We can replace the use of this package in those projects with much simpler inline logic (e.g. in many real-world projects, we safely switched to typeof n === 'number' since those projects later assumed and relied on the value being an actual number anyway).

Another example: is-regexp

You can test that something is a regular expression using instanceof: v instanceof RegExp.

However, in some situations (e.g. using virtual contexts), this won't work since RegExp isn't the same class which v originated from. In those cases, we need to use something like this:

Object.prototype.toString.call(obj) === '[object RegExp]'

If you don't want to inline such code, and need to support virtual contexts or similar, maybe a library makes sense.

However, in many cases, the projects did not support virtual contexts anyway (and did not want to). That opens us up to opportunities to simplify again to a simple instanceof.

Supporting older runtimes

Another potential area of improvement is that of older runtime support.

Quite a lot of very popular packages have very deep dependency trees of various polyfill-like modules. These generally exist for one or both of the following reasons:

To protect against global namespace tampering
To maintain support in runtimes which lack this functionality

Many of us do not need this level of backwards compatibility and could get large performance gains if we could trim it away.

It is important to note, of course, there are still people who do need to work in those constraints. This is why in this area, we often have been providing forks or alternatives rather than trying to change the existing packages (which wouldn't be open to such changes anyway).

Starting to improve things

I started to think about these particular areas back in 2018 or so, after seeing how large and deeply nested my node_modules were for even the smallest projects.

My first few attempts at change were to create some kind of ESLint plugin which can detect these packages and suggest they be removed. Every several months, I would have this same idea and try again but never really got where I wanted to be.

Through this time, I was at least contributing to various large projects to clean up and improve what I could (e.g. one i've contributed to for a long time is storybook).

Ecosystem cleanup

I then created the ecosystem cleanup, a repository for raising possible performance improvements across the ecosystem (basically an issue tracker). Again, this was basically me and my own personal issue tracker for some time, but at least it was visible in the open.

Soon after, I started to see people turning up in the issues and contributing to upstream projects. I was so happy to see this as I'd spent many years chipping away at this by myself, and wondering if I'm even making a difference. To see others joining in helped so much in knowing someone else cares.

Module replacements

While the cleanup project was and still is incredibly useful, we didn't really have anywhere to share with the rest of the community what good alternatives exist.

To solve this, I created the module replacements project.

This project basically holds some JSON lists of modules which can possibly be replaced and their suggested alternatives. These are currently split into three levels of "strictness" or "opinionatedness": native (modules which can be replaced with native functionality), micro-utilities (modules which may be replaceable by simple inline code), and preferred (modules which we think should be replaced with more performant alternatives).

Codemods

The next step of the replacements project was to create a set of codemods so we can automate the replacement of some of these modules.

Driven by @passle, this project quickly received a huge amount of contributions in the form of various codemods.

The codemod team have also done some good work porting these to the codemod platform. In future, we also want to provide them through some kind of CLI or auto fix rules.

e18e

The turning point where I feel all of us who care about this stuff found each other was e18e.

Bjorn was doing some great work improving the performance of astro, and Marvin had been similarly writing about speeding up the ecosystem. Eventually, our paths crossed and we had some great discussions on the side.

A small group of us worked together to see if we're all on the same page and if there's a community to be built out of this. Then came e18e!

Built to be a community space for people to collaborate on improving ecosystem performance, this has shown us how many people care about these things. So many have joined and have contributed massive amounts already. We're seeing speed ups and size reductions almost every day across the ecosystem.

Some thanks

The community is growing quickly and has too many people to thank for the contributions. However, I'd like to thank these people in particular for helping make this community possible:

Similarly, the people who were already working on projects contributing to the same goals in parallel:

@asleMammadam through tinylibs
@pi0 through unjs

Using tailwind v3 with lit elements

James Garbutt — Tue, 06 Dec 2022 19:18:43 +0000

Quite often I see people asking around the Lit community about how to use tailwind inside their Lit elements. This is going to be a brief overview of how you can make that happen.

I've written about this before, but the solutions I used in the past were often inconsistent or flaky. Fortunately, we now have a much more concrete solution available to us!

Setup

For simplicity, I'm going to go with a slightly unrealistic setup:

lit-element-starter-ts
directly calling postcss CLI on our built JS files

I'll assume you already have some similarly (or hopefully better) setup repo.

This means our source files will live in src/ and our built files will live in ./. For example, src/my-element.ts becomes lib/my-element.js on TypeScript build in this case.

Installing tailwind dependencies

To add tailwind to this setup, we need the following:

The last two are just nice to have, allowing us to lint our source CSS.

All of these are npm packages you can install with npm i.

How it'll all fit together

We will be using PostCSS to process our source files' CSS.

As part of that, PostCSS will call tailwind to handle the processing of tailwind's classes and what not.

We might also call stylelint so we can lint our source CSS.

In the end, we will have PostCSS write the now transformed sources back out to our build output.

Configuring postcss

Tailwind is essentially just a processor we usually call via either the Tailwind CLI or PostCSS.

In our case, we're going with PostCSS. So let's add a config file postcss.config.cjs:

module.exports = {
  syntax: 'postcss-lit',
  plugins: {
    tailwindcss: {
      config: './tailwind.config.cjs'
    }
  }
};

At the time of writing this, I had some trouble using ESM for these config files, hence the .cjs filename. Feel free to try it with .js or .mjs depending on your situation.

Two important things happen in the config file above:

We need to tell PostCSS how to read JS/TS files, specifically those containing Lit elements. We do that by specifying the syntax as postcss-lit.
We tell PostCSS we want to load tailwind as a plugin, to allow us to make use of tailwind's classes and everything else

Configuring Tailwind

Tailwind normally assumes you store your CSS separate from your JS.

For example, it will scan your JS sources for CSS classes so it can strip them (similar to JS tree shaking) from your CSS files.

This shouldn't work in our case because our CSS and JS lives in the same single file most of the time. In theory, this means every class would be "used" because tailwind would scan its own CSS for usages of its own classes... not what we want.

To solve this, we configure tailwind with a tailwind.config.cjs like so:

const {tailwindTransform} = require('postcss-lit');

module.exports = {
  content: {
    files: ['./*.js'],
    transform: {
      ts: tailwindTransform
    }
  }
};

We're basically telling it two things here:

Our source files which make use of tailwind's classes live at ./*.js. In this dumbed down case, this is true since we're transforming the already built (via tsc) JS. In your case, however, you may want to point it at your actual source files (the typescript).
A transform which will strip the CSS before tailwind does its class detection, so it doesn't detect its own CSS as usages

Configuring stylelint (optional)

Now that you have PostCSS setup, you can do all sorts of useful stuff. For example, we can setup stylelint to lint our source CSS.

To do that, you can create a .stylelintrc.json like so:

{
  "extends": "stylelint-config-standard",
  "customSyntax": "postcss-lit"
}

Again, we're just telling stylelint how to interpret our sources and to apply the standard lint rules.

You can execute this via npx stylelint src/**/*.ts for example.

If you use a bundler, maybe look for a stylelint plugin if you wish.

Run it

We can now do, for example:

npx postcss -r my-element.js

This would apply tailwind's transforms to our my-element.js file.

Again, this is a slightly unrealistic setup since we're transforming our TypeScript build output with PostCSS.

In real world repos you probably want this to run against a glob, like postcss -r build/**/*.js. Or if you use a bundler, use a postcss plugin in your bundler to apply it as part of the bundling process.

Using tailwind, postcss and stylelint with lit-element projects

James Garbutt — Mon, 20 Dec 2021 16:30:18 +0000

I've written various posts about using tailwind with lit components. Those solutions still work, but this post will outline a simpler method you can use for stylelint and postcss in general, too.

What's new?

As of postcss 8.3, postcss now has a native way of handling documents containing multiple stylesheets.

In the past, plugins worked around this limitation by fabricating one huge stylesheet made up of all the CSS found in your JS files.

On top of this, stylelint 14 introduces support for directly using a custom postcss syntax rather than needing a separate stylelint-bound plugin.

What does this mean?

This means the monolithic plugins of the past (which tried to handle all css-in-js types) will soon be deprecated if they haven't already, and instead you will simply specify the right "syntax" for reading the files in your project.

What's great is this also means we can now directly use frameworks like tailwind simply by configuring postcss correctly!

postcss-lit

To make use of this new capability, I have released postcss-lit.

This is a custom syntax implementation you can use with postcss to parse CSS inside your lit components.

Using PostCSS with lit

The most basic setup would be to use:

PostCSS CLI
postcss-lit

You can do this by following these instructions, creating a config file like so:

module.exports = {
  syntax: 'postcss-lit'
};

You can then transform a lit component using the postcss CLI, like so:

postcss -r src/my-element.js

This will process the CSS in your element and write back to the same file. In real world, you probably want to run this on build rather than changing your source file.

Using stylelint with lit

Very similar to using postcss with lit, you can use stylelint too. Using these instructions, you can create a stylelint config file like so:

{
  "extends": "stylelint-config-standard",
  "customSyntax": "postcss-lit"
}

You can then lint your lit components like so:

stylelint src/my-element.js

Using postcss & webpack with lit

If you use webpack, you can quite easily follow these instructions and create a config like so:

module.exports = {
  entry: './src/main.js',
  module: {
    rules: [
      {
        test: /\.js$/,
        use: ['postcss-loader'],
        exclude: /node_modules/
      }
    ]
  },
  output: {filename: 'bundle.js'}
};

This will process your CSS templates via postcss before producing your JS bundle. Simple as that.

Your bundle will now contain whatever CSS you configured postcss to transform.

Using tailwind

Just as easy, set everything up the same way as if you were going to use postcss by itself. Then follow these instructions, creating a postcss config like so:

module.exports = {
  syntax: 'postcss-lit',
  plugins: {
    tailwindcss: {}
  }
};

Now, tailwind has a concept of "content", files you want it to scan to detect which classes we have used. In our case, we want it to scan our JS (or typescript), though tailwind will have no idea how to parse these files.

To solve this problem, we need to configure tailwind like so:

const {tailwindTransform} = require('postcss-lit');

module.exports = {
  content: {
    files: ['./src/**/*.js'],
    transform: {
      js: tailwindTransform
    }
  }
};

Here we are simply telling tailwind to pass content files through our transform before it tries to detect class usages.

Under the hood, we need to do this so we can strip CSS templates from the content before scanning it, otherwise we'd incorrectly detect CSS names as usages.

You can then use tailwind inside your lit component:

class MyElement extends LitElement {
  static override styles = css`
    @tailwind base;
    @tailwind utilities;

    :host {
      display: block;
    }
  `;

  render() {
    return html`
      <h1 class="text-3xl">Hello!</h1>
    `;
  }
}

Wrap-up

In the past, these kinds of setup have been a real pain either solved by monolithic packages or by convoluted solutions. The introduction of customSyntax to stylelint is great, as a postcss syntax can be used as-is. Just the same, postcss' introduction of a Document allows us to parse multiple stylesheets from our JS files.

Some may ask why I have made postcss-lit specific to lit, too. This is mostly on advice from the stylelint and postcss authors, as they want to move away from having huge "solve all" packages.

The package is also very new, so feedback would be appreciated so much.

Big thanks to the vaadin team and IBM (mostly abdonrd) for testing this.

Strongly typed event emitters using EventTarget in TypeScript

James Garbutt — Sun, 04 Apr 2021 19:45:22 +0000

In case you weren't aware, you can have an event emitting class using only natively available APIs:

class State extends EventTarget {
  private __loading: boolean = false;

  public set loading(v: boolean) {
    this.__loading = v;
    this.dispatchEvent(new CustomEvent('loading-changed'));
  }

  public get loading(): boolean {
    return this.__loading;
  }
}

const state = new State();
state.addEventListener('loading-changed', () => {
  console.log(`LOG: loading = ${state.loading}`);
});

state.loading = true;
// LOG: loading = true

Of course, this is a very rough example but should get the idea cross. You don't need an event emitter library or some other dependency, the browser already has one!

The problem

The problem with this in TypeScript is that EventTarget has weak event types:

interface EventTarget {
  // ...
  addEventListener(
    type: string,
    listener: EventListenerOrEventListenerObject | null,
    options?: boolean | AddEventListenerOptions
  ): void;
}

This means we can't have any nice intellisense on valid events and their types:

// somewhere...
state.dispatchEvent(new CustomEvent<{x: number}>(
  'my-event',
  {
    detail: {
      x: 5
    }
  }
);

// elsewhere...
state.addEventListener(
  'my-event',
  // Following line will error because it must
  // be Event, rather than our custom event.
  (ev: CustomEvent<{x: number}>) => {
    // ...
  }
);

A possible solution

The way I solved this is as follows:

interface StateEventMap {
  'my-event': CustomEvent<{x: number}>;
}

interface StateEventTarget extends EventTarget {
  addEventListener<K extends keyof StateEventMap>(
    type: K,
    listener: (ev: StateEventMap[K]) => void,
    options?: boolean | AddEventListenerOptions
  ): void;
  addEventListener(
    type: string,
    callback: EventListenerOrEventListenerObject | null,
    options?: EventListenerOptions | boolean
  ): void;
}

const typedEventTarget = EventTarget as {new(): StateEventTarget; prototype: StateEventTarget};

class State extends typedEventTarget {
  // ...
}

const s = new State();

s.addEventListener('my-event', (ev) => {
  ev.detail.x; // WORKS! strongly typed event
});

Again, this isn't the perfect solution but it works until we have a better, easier one.

Explanation

For those uninterested in why this works, please do skip ahead!

To start, let's take a look at our addEventListener:

addEventListener<K extends keyof StateEventMap>(
  type: K,
  listener: (ev: StateEventMap[K]) => void,
  options?: boolean | AddEventListenerOptions
): void;

Here we are telling TypeScript this method can only be called with a type which exists as a key of StateEventMap.

We can define StateEventMap like so:

interface StateEventMap {
  'my-event': CustomEvent;
}

This would mean keyof StateEventMap is 'my-event'. It would be a union of strings if we had more keys.

Similarly, we are then defining that the listener must consume the value which exists at the specified key. In this case, StateEventMap['my-event'] is CustomEvent, so we're effectively stating:

addEventListener(
  type: 'my-event',
  listener: (ev: CustomEvent) => void,
  options?: boolean | AddEventListenerOptions
);

Keep in mind, you could actually define overloads this way too instead of using generics (one signature per event).

Now because EventTarget is an interface in TypeScript, we can extend it and add our strongly typed methods:

interface StateEventTarget extends EventTarget {
  addEventListener<K extends keyof StateEventMap>(
    type: K,
    listener: (ev: StateEventMap[K]) => void,
    options?: boolean | AddEventListenerOptions
  ): void;
  addEventListener(
    type: string,
    callback: EventListenerOrEventListenerObject | null,
    options?: EventListenerOptions | boolean
  ): void;
}

Note that we still keep the string overload in case there are other events we haven't mapped, and to implement the base interface correctly.

Finally, the true hackery here that I couldn't find a way to avoid is the cast:

const typedEventTarget = EventTarget as {new(): StateEventTarget; prototype: StateEventTarget};

class State extends typedEventTarget {
  // ...
}

We are essentially casting the EventTarget class (not the interface) as our strongly typed version. We then extend this instead of directly extending EventTarget. Remember, it is the same object, though.

Ideal solution

Admittedly, the solution here is not ideal and slightly hacky. The ideal solution, in my opinion, is that TypeScript introduces a generic version of EventTarget:

class State extends EventTarget<StateEventMap> {
 // ...
}

Something like this would be incredibly useful. One can hope :D

Wrap-up

Even if you don't use typescript, or don't want these strong types, I would recommend you give web APIs like EventTarget a try.

List of Web Component libraries and systems

James Garbutt — Wed, 31 Mar 2021 10:06:54 +0000

Web components are seeing huge adoption lately, so this is a short list of the libraries and design systems I've come across so far. There will be some I have forgotten, this is definitely an incomplete list, so feel free to comment the rest!

Material Design (Google)
vaadin
FAST (Microsoft)
Fluent UI (Microsoft)
GitHub elements (GitHub)
Lion (ING)
Spectrum Web Components (Adobe)
Lightning Web Components (Salesforce)
Clarity (VMWare)
Patterns (AXA)
Patternfly (RedHat)
Boston University Libraries
Shoelace
wired-elements
auro (Alaska Airlines)

In particular, we have used material design's web components for many years now and can highly recommend them. They are a great example of best practices and good web component architecture being put into use.

Similarly, Vaadin has been around for a long time in the web component community and is still going strong.

For anyone wanting to learn best practices and good architecture of web components, I'd recommend reading through the source of any of these libraries.

Using CSS shadow parts in web components

James Garbutt — Sat, 20 Mar 2021 12:45:37 +0000

CSS Parts are now supported in most modern browsers, so this is a brief write up on what they're useful for and how to use them.

Shadow DOM & styling

Let's say we have an example-button component, used like so:

<example-button>Some text</example-button>

Its inner shadow DOM may look like this:

<style>
  :host {
    display: inline-block;
  }
  button {
    color: hotpink;
  }
</style>
<button>
  <slot></slot>
</button>

This is a fairly atomic component in that it is fairly low level and can't be split up into further components.

In this case, we can style the example-button element itself through regular CSS selectors:

example-button {
  background: cyan;
  margin: 1em;
}

However, what if we want to change the text colour? You see we wanted a default colour of hotpink but this now means we can't override it from outside.

This is solved through CSS custom properties:

button {
  color: var(--example-button-colour, hotpink);
}

Now it will default to hotpink but allow us to override it like so:

example-button {
  --example-button-color: green;
}

This solves most cases where we want to give consumers the ability to style some of our component's internals.

Slightly more complex components

Now let's assume we have a more complex component, like a card:

<example-card heading="My heading">
  <p>My contents...</p>
</example-card>

With a shadow DOM like so:

<div class="container">
  <div class="heading">
    ${this.heading}
  </div>
  <div class="content">
    <slot></slot>
  </div>
</div>

The heading could have been a slot here, but that isn't always the case, so let's assume it couldn't be this time.

If we wanted to allow the consumer to style the heading, we could quickly end up with some CSS like this:

.heading {
  margin: var(--example-card-heading-margin);
  color: var(--example-card-heading-colour);
  padding: var(--example-card-heading-padding);
}

Of course, this becomes a bit of a pain.

The old way - `@apply`

One solution to this need for blocks of CSS rules already existed long ago when web components were still being finalised: the @apply rule.

It looked like this:

.heading {
  @apply --example-card-heading;
}

Which was set like this:

example-card {
  --example-card-heading: {
    margin: .2em;
    padding: .2em;
    color: hotpink;
  }
}

This tidied up those edge cases where people wanted to set several CSS properties at once, but it also opened the flood gates and made a bit of a mess (and lots of debates) so was ultimately deprecated and dropped.

The new way - `::part()`

The modern solution, now accepted in all modern browsers, is ::part().

Similar to how slots work, an element is given a part and CSS rules can reference that part.

Our card from earlier would have a shadow DOM like so:

<div class="container">
  <div class="heading" part="heading">
    ${this.heading}
  </div>
  <div class="content" part="content">
    <slot></slot>
  </div>
</div>

Which means you can style it via ::part():

example-card::part(heading) {
  padding: .2em;
  margin: .2em;
  color: hotpink;
}

You can even use pseudo-selectors after this:

example-card::part(heading):hover {

However, you cannot select a part within a part:

example-card::part(heading)::part(another-part) {

Forwarding parts

If you have nested components, you may want to expose an inner component's parts via your own component.

Let's say you have a DOM tree like so:

<root-element>
  #shadow-root (open)
    <child-element>
      #shadow-root (open)
      <div part="childpart"></div>
    </child-element>
</root-element>

If you want to expose childpart to consumers, you can use exportparts:

<child-element exportparts="childpart: rootpart">

This means your root-element will be exposing a part named rootpart.

The syntax here is essentially inner-name: outer-name and is a comma-separated list so you can expose multiple parts.

Wrap up

This is all cool stuff, but you should still carefully consider whether your styling really should be exposed or not.

If a page has been architected well, I would imagine most of the components are fairly atomic and wouldn't need to expose so much of their styling to the consumer. If you make good use of slots and CSS variables, you probably shouldn't need parts so often.

Where it could be useful is if you had a complex, high level component like an app shell or a data grid. In these cases you may need to expose a lot of styling.

How I created a vanilla web component

James Garbutt — Sat, 20 Feb 2021 12:56:36 +0000

I recently published shiki-element, a simple web component used to apply syntax highlighting to text via the shiki library.

It was a fun experience writing a vanilla web component for this using only modern solutions, so here's a ~~brief~~ (it didn't end up so brief after all) write up in case anyone else wants to try the same. Also to show you don't always need a framework.

NOTE: I understand there's a fair amount of boilerplate to follow, in real world cases I'd normally suggest choosing focused libraries to fill the gaps and something like lit-element for the rendering/propagation layer. This is just to demonstrate how you can make a vanilla component and my particular experience.

The objective

The objective I had was to create a web component which wraps the shiki library and has the following interface/consumption:

<shiki-highlight language="javascript">
function hello() {
  return 'hello world';
}
</shiki-highlight>

I didn't want to use any frameworks or libraries, zero-dependencies other than the shiki dependency if possible.

I also wanted to go ESM-only, i.e. no CommonJS support and no CommonJS dependencies.

Initial project setup

My immediate thought was to throw together the basic tooling stack I wanted:

With all of my sources in a src/ directory and my tests in src/test/.

TypeScript

Seeing as I wanted to write ESM and output ESM, my tsconfig.json was fairly straight forward:

{
  "compilerOptions": {
    "target": "es2017",
    "module": "esnext",
    "moduleResolution": "node",
    "declaration": true,
    "outDir": "./lib",
    "strict": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "noImplicitReturns": true,
    "noFallthroughCasesInSwitch": true,
    "noUncheckedIndexedAccess": true,
    "forceConsistentCasingInFileNames": true
  },
  "include": [
    "src/**/*.ts"
  ]
}

ESLint

To keep things simple, I chose to use Google's lint config and tweak a couple of rules for my own preference in .eslintrc.json:

{
  "extends": [
    "eslint:recommended",
    "google",
    "plugin:@typescript-eslint/eslint-recommended",
    "plugin:@typescript-eslint/recommended"
  ],
  "plugins": ["@typescript-eslint"],
  "rules": {
    "indent": "off",
    "comma-dangle": ["error", "never"],
    "spaced-comment": "off",
    "@typescript-eslint/no-unused-vars": "off",
    "@typescript-eslint/no-inferrable-types": "off"
  }
}

I disabled the no-unused-vars rule as the TypeScript compiler does such a check already, and better than the one ESLint does (via noUnusedLocals and noUnusedParameters).

I also disabled no-inferrable-types as I prefer declaring my types than relying on inference, for consistency.

Prettier

I also chose to add my own .prettierrc.json to configure a few Prettier options to my preference, but the defaults are probably fine for most people.

web-test-runner

I configured web-test-runner to use my transpiled tests via puppeteer in web-test-runner.config.mjs:

import {puppeteerLauncher} from '@web/test-runner-puppeteer';

export default {
  nodeResolve: true,
  files: 'lib/test/**/*_test.js',
  testFramework: {
    config: {
      ui: 'bdd'
    }
  },
  coverage: true,
  coverageConfig: {
    include: ['lib/**/*.js'],
    exclude: ['lib/test/**/*.js']
  },
  browsers: [
    puppeteerLauncher()
  ]
};

Again, fairly simple, I want to use mocha's BDD interface with test coverage enabled, launched via puppeteer.

Keep in mind, I chose to run WTR against my transpiled sources as they're almost equal to my actual sources. It is possible, however, to have WTR run against your TypeScript sources by using the esbuild plugin.

Assertions

The last missing piece of my setup was what I'll use for assertions in my tests.

I'd usually opt for chai, but it is increasingly becoming outdated (or has already, to be honest). It provides no official ESM entrypoint, which means I would be forced to support CommonJS in my stack in order to use it. This would mean introducing a bundle in my build process, unacceptable!

So I happily threw chai away, and pestered people for suggestions of alternatives which support ESM. This is where I came across uvu.

uvu is very small, supports TypeScript and is published as ESM! Great.

It does come with its own mocha-alternative but I'm not sure I'm a fan of the design, so I chose to use only the uvu/assert module it contains and stick with mocha.

Finally, some code 👀

I suspect its unusual to throw together a whole project setup before even writing a line of code, so feel free to skip most of the above 😬

A simple component

To begin with, remember our expected HTML usage:

<shiki-highlight language="javascript">
console.log(12345);
</shiki-highlight>

So we know from this, our component needs to roughly look like so:

class ShikiHighlight extends HTMLElement {
  public language?: string;
}

customElements.define('shiki-highlight', ShikiHighlight);

Right now, this'll render nothing but has the right interface.

Attributes and properties aren't the same

We have a language property, but a property is not the same as a HTML attribute. So our language attribute will do nothing right now, and won't sync with the property.

// These are not equivalent
node.setAttribute('language', 'javascript');
node.language = 'javascript';

This is solved by using the attributeChanged callback and observedAttributes:

class ShikiHighlight extends HTMLElement {
  public language?: string;

  public static get observedAttributes(): string[] {
    return ['language'];
  }

  public attributeChangedCallback(
    name: string,
    oldValue: string,
    newValue: string
  ): void {
    if (name === 'language') {
      this.language = newValue;
    }
  }
}

The observedAttributes static is used by the browser to determine which attributes to trigger the change callback for. The change callback (attributeChangedCallback) is fired each time one of the observed attributes changes value.

This means any time language changes on the element, our property will also be set to the same value.

NOTE: for now, synchronisation won't happen the other way, i.e. the property being set won't set the attribute.

Creating a shadow root

Ultimately, we want to render our syntax highlighted nodes in a shadow root so we don't affect the consumer's DOM tree (the "light DOM").

So we need a root:

public constructor() {
  super();
  this.attachShadow({mode: 'open'});
}

This'll result in DOM like so:

<shiki-highlight>
  #shadow-root (open)
    <!-- syntax highlight result will live here -->
  function hello() {
    return 'hello world';
  }
</shiki-highlight>

Observing light DOM contents

We need something to syntax highlight... the contents of the element if you remember from our previous example:

<shiki-highlight>
console.log(12345); // This is text content of the element
</shiki-highlight>

We need to observe changes to this text content and trigger a new syntax highlight each time, outputting the resulting HTML to the shadow root we created earlier.

This can be done by a MutationObserver:

public constructor() {
  super();
  this.attachShadow({mode: 'open'});

  this._observer = new MutationObserver(() =>
    this._domChanged());
}

public connectedCallback(): void {
  this._observer.observe(this, {
    characterData: true,
    subtree: true,
    childList: true
  });
}

public disconnectedCallback(): void {
  this._observer.disconnect();
}

protected _domChanged(): void {
  // Fired any time the dom changes
}

connectedCallback is called by the browser when the element is added to the DOM tree, disconnectedCallback is called when it is removed from the DOM tree.

In our case, we want to observe the light DOM (this) when connected, and stop observing when disconnected.

We are observing changes to the text (characterData) and child nodes (childList).

NOTE: A bit of a TIL, setting textContent does not mutate characterData, in fact it mutates the childList as it results in setting a new text node as a child.

Our _domChanged can be implemented like so:

protected _domChanged(): void {
  this._render();
}

protected _render(): void {
  // do some syntax highlighting here
}

Observing property changes

Remember our language property? We need to re-render each time that changes as the syntax highlighting will differ per language.

We can implement this kind of observer by getters and setters:

// Change our language property to be protected
protected _language?: string;

// Replace the original property with a getter
public get language(): string|undefined {
  return this._language;
}

// and a setter which triggers a re-render
public set language(v: string) {
  this._language = v;
  this._render();
}

Now any time we set the language property, we will re-render.

Remember we also need to ensure the previous attribute changed callback sets language (and not _language), so it triggers a re-render too.

Implementing the render method

Finally, we need to do the work for syntax highlighting:

protected _render(): void {
  const highlightedHTML = highlightText(this.textContent ?? '');
  this.shadowRoot.innerHTML = highlightedHTML;
}

Pretty basic, we pass the light DOM text content to our highlighting library, which then returns HTML we append into our shadow root.

Our DOM will then look like this:

<shiki-highlight language="javascript">
  # shadow-root (open)
    <pre class="shiki"> ... </pre>
  console.log(12345);
</shiki-highlight>

Tests and what not

After this, I wrote a bunch of unit tests using uvu and mocha:

import {assert} from 'uvu/assert';

describe('shiki-highlight', () => {
  it('should work', () => {
    assert.is(actual, expected);
  });
});

Which I ran via WTR:

npx web-test-runner

I also setup a github workflow and some package scripts (lint, format, etc.).

Wrap-up

Again, I'm writing this really because I enjoyed being able to produce a component using vanilla JS and modern tooling.

I've given no consideration to older browsers and have relied on a fair amount of features only the latest support.

There is nothing wrong with bundling, either, I just wanted to avoid it in this case as it'd be nice to publish and write ESM as-is.

You can view the finished component here:
https://github.com/43081j/shiki-element

You can see a demo here (may load a little slow initially since shiki is a bit on the chunky side):
https://webcomponents.dev/preview/cQHUW8WJDlFAKqWpKibc

Not everything needs a framework, or a base library. The point at which you'll likely need to consider one is when you need state or more complex data propagation/observation.

Things to watch for in TypeScript 4.2 onwards

James Garbutt — Wed, 30 Dec 2020 13:02:33 +0000

TypeScript is still on 4.1 at the time of writing this, but here's a few features currently being worked on or discussed which I found interesting.

Static index signatures

Index signatures usually look like this:

class Foo {
  // All keys have numeric values
  [key: string]: number;
}

const obj = new Foo();
obj['a']; // number
obj['b']; // number

However, what if we want to index into the class itself? Like Foo['a']. This is where "static index signatures" come in:

class Foo {
  // All static keys have numeric values
  static [key: string]: number;
}

Foo['a']; // number
Foo['b']; // number

`querySelector` type inference

Currently, querySelector can infer the type of the element you're selecting if it is a simple selector:

document.querySelector('div'); // HTMLDivElement

However, this isn't possible right now with anything more complex:

document.querySelector('div p'); // Element
document.querySelector('div.foo'); // Element

There's discussion going on around improving the built-in types for this to "parse" the string you pass in and infer the correct type:

document.querySelector('div p'); // HTMLParagraphElement
document.querySelector('div.foo'); // HTMLDivElement

This'd be awesome but I do wonder what the performance hit would be. We will see...

Leading/middle rest elements

You can currently do the following:

function test(...args: string[]) {}

test('a', 'b'); // fine
test('a', 5); // error

But you can't specify the surrounding elements. A new proposal would solve this and allow the following:

function test(...args: [...string[], number]): void;

function test2(...args: [number, ...string[], number]): void;

test('a', 'b'); // error
test('a', 'b', 5); // fine
test('a', 5, 'b'); // error

test2(5, 'a', 'b', 6); // fine
test2(5, 'a', 'b'); // error

This can be pretty useful to be more specific about what elements the arguments array should contain.

`override` keyword

My favourite new feature, the override keyword and the associated noImplicitOverride compiler option.

This is exactly as you'd expect, it allows you to specify that you're overriding an inherited method:

class Foo {
    x(): number {
        return 5;
    }
}

class Bar extends Foo {
    override x(): number {
        return 6;
    }
}

With the noImplicitOverrides option enabled, this means we will get a compiler error if we don't use the keyword on overridden methods.

This is great as I think method overrides are too weak right now. It is too easy to override a method without realising, or to forget a parent class has a same named method, and so on. Just a bit more strictness to catch some sneaky problems.

`noPropertyAccessFromIndexSignature`

Enabling this compiler option means you can only access index signatures using square brackets:

interface Foo {
  b: number;
  [key: string]: number;
}

declare const test: Foo;

test.b; // fine
test.a; // error
test['a']; // fine

Comes down to personal preference, I suppose.

Inferred template literal types

This one feels like it'll break a lot of stuff:

const foo = ['a', 'b'];
const bar = foo.map(n => `${n}-xyz`);

// bar is now Array<`${string}-xyz`>
bar.push('foo-xyz'); // works
bar.push('xyz'); // error!

Where the array used to be inferred as string[], it is now inferred as a template literal type array.

Very cool but also how many times have people mapped an array this way and pushed something which doesn't follow the pattern? Seems like one hell of a breaking change :D

Wrap-up

All these are very interesting changes.

However, the querySelector changes do make me wonder how much worse they will be for performance. Similarly, the template literal inference feels like it will break a lot of stuff.

But we will see, either way these will be some nice changes to play around with and try out.

Using tailwind at build-time with lit-element

James Garbutt — Tue, 29 Dec 2020 21:14:41 +0000

Outdated solution!

There's a much easier way to do this now:

Using tailwind v3 with lit elements

James Garbutt ・ Dec 6 '22

Read on if the new solution doesn't work, or you just prefer this one...

A few days ago, I wrote about using tailwind with web components at run-time:

Using tailwind at run-time with web components

James Garbutt ・ Dec 27 '20

#tailwindcss #webcomponents #webdev

At the time, I was actually trying to figure out how to do this at build-time but was struggling to find an existing solution. Good news: I found one!

Keep in mind, this example is specific to lit-element.

My Setup

As in my previous article, the same setup was used:

A single web component (lit-element in this case)
esbuild
TypeScript

Using a lit-element component:



class MyElement extends LitElement {
  static styles = css`
    /*
     * Somehow we want tailwind's CSS to ultimately
     * exist here
     */
  `;

  render() {
    // We want these tailwind CSS classes to exist
    return html`<div class="text-xl text-black">
      I am a test.
    </div>`;
  }
}

The problem

As discussed in my last post, tailwind doesn't seem to support shadow DOM or web components in general out of the box.

I previously solved this by using twind, a great little library which behaves as a 'tailwind runtime' and produces the correct stylesheets at run-time.

However, not everyone wants a run-time solution, some have static enough CSS they would rather build it once and forget.

So, as you saw in the example above, our aim is to inject tailwind's CSS into the component's stylesheet.

The investigation

Getting to the solution below took quite some time over the past day or so, involved finding a few bugs and discovering new tools.

First of all, I did some googling and found:

postcss-js

This is a postcss plugin for dealing with "CSS in JS". Sounds promising!

But no, this is a plugin for converting between CSS objects (actual JS representations of CSS) and CSS strings. We don't want this, we want to transform CSS strings in-place.

babel plugin

The babel plugin extracted CSS from template literals, passed them through postcss and replaced the original. Exactly what we need!

But... it is a babel plugin and we don't want to use babel. So this one was a no, too.

rollup plugin

A rollup plugin or two exist which do the same as "postcss-js": they transform to and from CSS objects.

Again, not what we want.

Custom rollup plugin

I then made my own rollup plugin, which extracted template literals the same as the babel plugin did and processed them with postcss.

This did work, but seemed like overkill and tied us into rollup. I didn't really want to have a solution which depends on another build tool being used.

Fun to make my own rollup plugin, though, so good experience.

postcss-jsx (aka postcss-css-in-js)

Andrey (postcss maintainer) at this point recommended I use "postcss-jsx". I had seen this while googling previously but couldn't quite figure out from the docs how to get it working with my sources.

It sounded like the right way to go, though, so I tried again!

First try, I managed to get it processing the CSS from my element! Success. It resulted in a huge stylesheet (all of tailwind) but looked like it worked.

Bug 1

Not so fast, though. I tried this in a browser and was met with a good ol' syntax error. The first bug: postcss-jsx doesn't escape backticks in the output CSS.

Tailwind's CSS contains comments with backticks, so we end up producing syntactically incorrect code like this:



const style = css`
  /** Tailwind broke `my code with these backticks` */
`;

At this point, I noticed postcss-jsx is unmaintained and the folks at stylelint have forked it. So I filed the first bug in my investigation:

https://github.com/stylelint/postcss-css-in-js/issues/89

Bug 2

I fixed postcss-css-in-js locally to escape backticks, so I now got some output.

But this won't work for anyone else until the package is fixed, of course. So I figured we can get around it: use cssnano to strip comments entirely - making those backtick comments conveniently disappear.

Installed cssnano, added it to my postcss config, and used the "lite" preset as I only wanted empty rules and comments removing.

Turns out, cssnano-preset-lite doesn't work with postcss-cli. Another bug:

https://github.com/cssnano/cssnano/issues/976

Bug 3

I almost forgot, postcss-css-in-js also had a 3rd bug: it produces an AST like this:



Document {
  nodes: [
    Root { ... },
    Root { ... }
  ]
}

Turns out, postcss has trouble stringifying nested roots. Bug raised and even tried a PR this time:

https://github.com/postcss/postcss/issues/1494

UPDATE: fixed in PostCSS 8.2.2!

Solution

After this excellent amount of fun finding bugs and researching solutions, I finally got to one which works.

Source

To include tailwind's CSS, we do exactly as in their docs:



export class MyElement extends LitElement {
  public static styles = css`
    @tailwind base;
    @tailwind utilities;
    /* whatever other tailwind imports you want */
  `;
  // ...
}

These @tailwind directives will later be replaced with tailwind's actual CSS by postcss.

Dependencies

As mentioned above, we needed the following:



$ npm i -D postcss @stylelint/postcss-css-in-js tailwindcss postcss-syntax postcss-discard-comments postcss-discard-empty

Build script (`package.json`)



{
  "scripts": {
    "build:js": "tsc && esbuild --bundle --format=esm --outfile=bundle.js src/index.ts",
    "build:css": "postcss -r bundle.js",
    "build": "npm run build:js && npm run build:css"
  }
}

Running npm run build will:

Run typescript (with noEmit: true) just for type-checking
Run esbuild to create a JS bundle
Run postcss and replace the contents of the JS bundle in place

`tailwind.config.js`



module.exports = {
  purge: [
   './bundle.js'
  ]
};

Here, bundle.js is what we produced with esbuild earlier on. We want to purge unused styles from our bundle.

`postcss.config.js`



module.exports = {
  syntax: require('@stylelint/postcss-css-in-js'),
  plugins: [
    require('tailwindcss')(),
    require('postcss-discard-comments')(),
    require('postcss-discard-empty')()
  ]
};

Here:

syntax tells postcss how to read our JS file
tailwindcss injects tailwind's CSS and then purges unused styles
postcss-discard-comments discards comments (which prevents bug 1 above)
postcss-discard-empty discards the empty rules tailwind left behind after purging

Note: cssnano can be used instead of the last 2 plugins but we didn't in this case because of bug 2 above

Build it

Our build script from before should now work:



$ npm run build

If we want to strip all those unused styles and make use of the purge option in our config, we need to specify NODE_ENV:



$ NODE_ENV=production npm run build

Tailwind will pick this up and purge unused styles.

Enabling purging in both dev and prod

If you always want purging to happen, simply change your tailwind config to look like this:



module.exports = {
  purge: {
    enabled: true,
    content: [
      './bundle.js'
    ]
  }
};

This is described more here.

Optimise it

We can do a bit better than this. Right now, we are producing a tailwind stylesheet for each component.

If we have multiple components, each one's stylesheet will have a copy of the tailwind CSS the whole app used (as we're operating against the bundle, not individual files).

So we'd probably be better off having a single tailwind template many components share:



// styles.ts
export const styles = css`
  @tailwind base;
  @tailwind utilities;
`;

// my-element.ts
import {styles} from './styles';
export class MyElement extends LitElement {
  static styles = [styles];
  public render() {
    return html`<p class="p-4">One</p>`;
  }
}

// another-element
import {styles} from './styles';
export class AnotherElement extends LitElement {
  static styles = [styles];
  public render() {
    return html`<p class="p-6">Two</p>`;
  }
}

This means we will produce one monolithic tailwind stylesheet all of our components re-use.

In the example above, .p-6 and .p-4 (the classes used in the render methods) will both exist in the stylesheet with all other unused styles stripped.

Whether this is an optimisation or not does depend on your use case. Just remember the "purging" happens on the bundle, not the individual files.

Useful links (packages we used)

Wrap-up

As I said in my previous post, run-time vs build-time is a project-based preference I think. Some of you will be better off using the run-time twind solution, others will be better off using this build-time solution.

If your styles are very static (i.e. you don't really dynamically use any at run-time) or you already have a similar postcss build process, you should probably process Tailwind at the same time.

The cssnano inclusion is a hack in my case, to get around bug 2 mentioned above. Though you probably want to use it anyway to save some bytes in production.

Have fun!

String manipulation types in TypeScript 4.1

James Garbutt — Mon, 28 Dec 2020 17:26:45 +0000

TypeScript recently introduced "template literal types", these basically allow us to use template string like semantics when creating literal types.

Along side this new functionality came some fairly useful new utility types: string manipulation types.

Template literal types

For example:

type Foo = 'foo';
type Bar = 'bar';
type FooBar = `${Foo | Bar}`; // "foo" | "bar"

As you can see, the new thing here is that we can interpolate other types within another string literal type.

This is pretty powerful stuff as it means we could infer strings based on other string-like types.

A few possible use cases:

${keyof T}-changed to infer "foo-changed"-style events
Enumerating combinations of string literal types as above
Inferring part of a string literal type

I won't go into this too much, but you can read more here.

String manipulation types

There are 4 new string manipulation types:

`Uppercase<T>`

Transforms a string literal type to uppercase:

type Foo = 'foo';
type UpperFoo = Uppercase<Foo>; // "FOO"

`Lowercase<T>`

Transforms a string literal type to lowercase:

type FooBar = 'FOO, BAR';
type LowerFooBar = Lowercase<FooBar>; // "foo, bar"

`Capitalize<T>`

Transforms a string literal type to have the first character capitalized:

type FooBar = 'foo bar';
type CapitalizedFooBar = Capitalize<FooBar>; // "Foo bar"

`Uncapitalize<T>`

Transforms a string literal type to have the first character lowercased:

type FooBar = 'Foo Bar';
type CapitalizedFooBar = Uncapitalize<FooBar>; // "foo Bar"

How?

If, like me, you wondered how these types can possibly work... the answer is compiler magic.

Usually TypeScript's utility types ultimately drill down to something you could have written yourself, for example:

// Record is defined as follows inside TypeScript
type Record<K extends keyof any, T> = {
    [P in K]: T;
};

// Before it existed, people were writing things like:
type Record = {[key: string]: any};

However, this time around, these new types are built into the compiler and cannot (easily) be written by us. As you can see:

// intrinsic is some special keyword the compiler
// understands, expected to never be used in userland code.
type Uppercase<S extends string> = intrinsic;

// under the hood, it uses this:
function applyStringMapping(symbol: Symbol, str: string) {
    switch (intrinsicTypeKinds.get(symbol.escapedName as string)) {
        case IntrinsicTypeKind.Uppercase: return str.toUpperCase();
        case IntrinsicTypeKind.Lowercase: return str.toLowerCase();
        case IntrinsicTypeKind.Capitalize: return str.charAt(0).toUpperCase() + str.slice(1);
        case IntrinsicTypeKind.Uncapitalize: return str.charAt(0).toLowerCase() + str.slice(1);
    }
    return str;
}

Examples

A few possible uses of this:

/*
 * Technically you could use this to require UPPERCASE
 * or lowercase...
 */
declare function foo<T extends string>(str: T extends Uppercase<T> ? T : never): void;

foo('ABCDEF'); // Works
foo('abcdef'); // Error

/*
 * Or you might want a method to return a transformed
 * version of a string...
 */
declare function toUpper<T extends string>(val: T): Uppercase<T>;

toUpper('foo' as string); // string
toUpper('foo'); // "FOO"

Wrap-up

If you want to know more about these types, see here:

https://www.typescriptlang.org/docs/handbook/2/template-literal-types.html

They're very cool and this new functionality opens up many doors. What was previously weakly typed as a string can probably now be strongly typed in many cases.

Give them a go!

Using hanbi for your JavaScript testing

James Garbutt — Sun, 27 Dec 2020 18:39:09 +0000

This is just a brief write-up of why you might want to use hanbi and how.

What is it?

When writing tests in JavaScript, it is inevitable that you'll eventually want to mock/stub out some functionality in your code.

hanbi is one of the many solutions to this - a small library for stubbing out and spying on functions.

Why?

Most people these days immediately install their go-to testing stack without a second thought when creating a new repository. Often, this of course means installing "sinon".

It is a good library, but it has grown over the years to become very bloated... trying to solve everyone's problems in one go and trying to cover every possible use case.

Just a few of the reasons I wanted to move off it:

It is hundreds of KiB in size (not such a problem as a dev-dependency, but does not scale well in CI)
It tries to be too helpful (calledThrice is too far)
It doesn't play nice with TypeScript (the types work, but they are far too over-complicated and have to be)

For these reasons and more, I just wanted a light alternative which was focused on only handling stubs/spies. No extra help, no 'magic', no shortcuts. Just a focused base implementation.

Some advantages

I love focused libraries which do less but do it well. Examples are esbuild, rollup, prettier and so on.

Hanbi is just the same, very focused with an aim to stay that way.

It is also written in TypeScript, and in a way which means its types work very smoothly and logically. Less crazy types = better.

How to use it

Using hanbi is incredibly simple.

It provides us a way to create a "spy" which monitors its own calls, and a way to create a "stub" which effectively replaces some function with a spy.

We can install it pretty easily:

$ npm i -D hanbi

Spying

For when we want to track the calls of an anonymous function (like an event handler), we can simply create a "spy".

These spies can then be passed in to whatever functionality you're trying to test as if they were their "real" counterparts.

const spy = hanbi.spy();
window.addEventListener('load', spy.handler);
spy.called; // true once the event fires

This is useful when we need to pass in a callback function, test an event handler or something similar.

Stubbing

For when we need to mock out a piece of functionality which we are expecting to trigger, we can stub it.

For example, preventing an object from sending an actual request off or similar.

class Foo {
  myMethod() {
    return 5;
  }

  myOtherMethod() {
    return this.myMethod();
  }
}
const instance = new Foo();
const stub = hanbi.stubMethod(instance, 'myMethod');

instance.myMethod(); // undefined
instance.myOtherMethod(); // undefined

stub.returns(6);

instance.myMethod(); // 6
instance.myOtherMethod(); // 6

stub.called; // true

Assertions/state

There are a few main assertions and pieces of state you can use on a spy/stub:

const spy = hanbi.spy();

// Gets a specific call
const call = spy.getCall(2);

call.args; // The arguments passed when it was called
call.returnValue; // The value that was returned
call.thisValue; // The `this` at the time it was called

// Determines if the spy was called
spy.called;

// Determines if the spy was called with specific args
spy.calledWith('arg1', 'arg2');

// Determines if the spy ever returned a specific value
spy.returned('foo');

Wrap-up

Again, this isn't meant to be taking on all those existing testing libraries you make use of today. I still contribute to sinon and keep its TypeScript types well maintained when I can.

This is just a far more focused alternative for anyone interested.

I came up with it primarily to solve a problem I had: sinon was slowing down CI builds to a noticeable amount, and was only used for a fraction of its functionality.

If you give it a try, do let me know your thoughts and feel free to make any suggestions in the GitHub issues.

DEV Community: James Garbutt

Migrating from chokidar 3.x to 4.x

Dependency graph difference

Changes in 4.x

Life without globs

Feedback

Cleaning & speeding up the JS ecosystem - Journey so far

Thoughts on micro-utilities

Example: is-number

Another example: is-regexp

Supporting older runtimes

Starting to improve things

Ecosystem cleanup

Module replacements

Codemods

e18e

Some thanks

Using tailwind v3 with lit elements

Setup

Installing tailwind dependencies

How it'll all fit together

Configuring postcss

Configuring Tailwind

Configuring stylelint (optional)

Run it

Using tailwind, postcss and stylelint with lit-element projects

What's new?

What does this mean?

postcss-lit

Using PostCSS with lit

Using stylelint with lit

Using postcss & webpack with lit

Using tailwind

Wrap-up

Strongly typed event emitters using EventTarget in TypeScript

The problem

A possible solution

Explanation

Ideal solution

Wrap-up

List of Web Component libraries and systems

Using CSS shadow parts in web components

Shadow DOM & styling

Slightly more complex components

The old way - @apply

The new way - ::part()

Forwarding parts

Wrap up

How I created a vanilla web component

The objective

Initial project setup

TypeScript

ESLint

Prettier

web-test-runner

Assertions

Finally, some code 👀

A simple component

Attributes and properties aren't the same

Creating a shadow root

Observing light DOM contents

Observing property changes

Implementing the render method

Tests and what not

Wrap-up

Things to watch for in TypeScript 4.2 onwards

Static index signatures

querySelector type inference

Leading/middle rest elements

override keyword

noPropertyAccessFromIndexSignature

Inferred template literal types

Wrap-up

Using tailwind at build-time with lit-element

Outdated solution!

Using tailwind v3 with lit elements

James Garbutt ・ Dec 6 '22

Using tailwind at run-time with web components

James Garbutt ・ Dec 27 '20

My Setup

The old way - `@apply`

The new way - `::part()`

`querySelector` type inference

`override` keyword

`noPropertyAccessFromIndexSignature`

Build script (`package.json`)

`tailwind.config.js`

`postcss.config.js`

`Uppercase<T>`

`Lowercase<T>`

`Capitalize<T>`

`Uncapitalize<T>`