ladle VS pedalboard

After another look at issue #100, we can tell next/image that it should skip the optimization if the component is rendered in Ladle. That is fine, because the bandwidth does not play a big role during the development. With the following code placed inside .ladle/components.tsx ...

What you guys think of Ladle?

The new set of web tools is coming and brings huge performance wins. Ladle is using them to provide a significantly faster environment for developing, sharing and testing your React components. Are you ready to give it a try? Also, check our GitHub and give us ⭐.

I notice that changes to the actual story are not reflected in Ladle immediately and require a page refresh. The console spits out that Vite HMR received a “hot update” but nothing happens. Strange. Storybook on the other hand reloads as expected. Unless I’m doing something wrong here, this is a bug that should be taken care of by the Ladle team as soon as they can. Seems that there is an issue already on the matter.

Can you reproduce it with https://stackblitz.com/edit/ladle & create an issue at https://github.com/tajo/ladle/issues?

You can check out some demo examples in this Storybook, and see the code in the pedalboard repo.

Turns out there are tools for that and one of them is called typescript-coverage-report by Alex Canessa and I’m going to give it a try now and implement it in my Pedalboard monorepo.

Also, all the code mentioned here can be found in the GitHub repository for this plugin. Put your testing helmet on, here we go!

My Components package currently supports regular plain-old CSS (not that there’s anything wrong with it), and I thought it was a good time to introduce SASS to it, but the package is not a ordinary “Webpack-build-that-s#!t-for-me”. I’m using TSC (TypeScript Compiler) to generate the artifacts - What it means is that TSC is compiling 2 versions of the component, ESM and CJS. Once we have these, we’re taking the ESM outcome and bundling it using esbuild. You can read more about it here, but if to put it visually:

In this post I will write a test suite for my @pedalboard/stylelint-plugin-craftsmanlint. We will be using jest-preset-stylelint to help us with that, and as a bonus, I’ll fortify the plugin’s TypeScript support.

For reference, below is an image of the Pagination component, and you can find it’s code here:

Disclaimer - I’m going to apply the following steps on my Pedalboard monorepo. Working with monrepos is a bit different, and I will relate to that during the process, but be aware that applying Chromatic on a “simple” repo is even simpler.

I have noticed that although the build process for packages under my “pedalboard” Monorepo creates different artifacts (CJS, ESM and types - you can read about it in more details in my “Hybrid NPM package through TypeScript Compiler (TSC)” post) it does not create a single bundle for the entire package.

I will attempt to introduce this visual regression testing to my Pagination component from the @pedalboard/components package. So here we go.

So let’s see how this tool works and what we can do with it. I’m gonna do my experimenting over my Pagination component which resides on the @pedalboard/components package. Let’s go!