Lightnews — Scholar-powered news

Bart Veneman @veneman.dev · 17h

If they let me, of course.

Bart Veneman @veneman.dev · 17h

I think I'll go their open source plan after all. Wallace's website source is public now, so that shouldn't be an issue.

1 2

Bart Veneman @veneman.dev · 17h

Ahw fffffff... Apparently I'm already 50% on my Netlify credits for this month. There's more traffic than usual last 30 days and I guess I'm running too many playwright tests on each PR push.

1 2

Bart Veneman @veneman.dev · 1d

RIP Edward Reekers 😔 nos.nl/artikel/2585...

Voormalig Kayak-zanger Edward Reekers overleden

Twee maanden geleden maakte hij bekend dat hij uitgezaaide longkanker had.

nos.nl

Bart Veneman @veneman.dev · 1d

What if you can also set a minimum coverage ratio for individual files?

A terminal showing this:

Checking 211 files...
Analyzed 3309 coverage entries
Success: line coverage is 0.89
Failed: Not all files meet the minimum line coverage of 0.7:

- https://projectwallacecom-17odovju6-project-wallace.vercel.app/_app/immutable/assets/Meter.lNW2i1FX.css
Coverage: 0.63
- https://projectwallacecom-17odovju6-project-wallace.vercel.app/_app/immutable/assets/17.dDN0iyBr.css
Coverage: 0.69
- https://projectwallacecom-17odovju6-project-wallace.vercel.app/_app/immutable/assets/11.CYFb5tM-.css
Coverage: 0.68

Bart Veneman @veneman.dev · 1d

Why not render all the uncovered bits while we're at it?

This is turning into a pretty big project 😂

Terminal output showing CSS Coverage data. I starts with checking 211 files, then analyzing 3309 coverage entries. It then shows a success message that the coverage is 0.89.
Below that is a report of every not-covered bit of CSS. For each block it shows the uncovered line numbers in red and 3 lines before and after the block for additional context.

1 2

Bart Veneman @veneman.dev · 1d

Funny how in my previous job one of my success metrics was to keep the number of PR's raised as low as possible. Now doing 3-5 PR's per day and it's fun but weird.

Bart Veneman @veneman.dev · 1d

Writing a tiny parser to scrape urls from CSS at-import rules because css-tree is a pain in the butt when deploying an esm-only package.
And 2MB+ is too much anyway. I'm thinking about forking csstree and stripping all the heavy cruft from it.

Bart Veneman @veneman.dev · 2d

Because playwright/test ships with additional test helpers and an assertion library. Last time I used puppeteer it didn't have that because that's not it's purpose.

1 1

Bart Veneman @veneman.dev · 2d

For testing: yes. For other jobs: it depends, I guess.

1

Bart Veneman @veneman.dev · 2d

IT'S WORKING!!! 🎉

🎭 Every @playwright.dev test collects bits of CSS Coverage
💾 Each PW test stores the coverage result in a JSON file and stores as GitHub artifact
🗂️ GitHub Action grabs the artifact and feeds into tiny CLI tool
🥳 CLI accepts `minLineCoverage` arg and passes or fails the job

🤩🤩🤩🤩🤩🤩

Part of the report of a GitHub Action. It shows a step called 'Analyze coverage'. That shows CLI output that apparently checked 212 files, found 3390 coverage entries and calculated CSS line coverage at 90%.

2 3

Bart Veneman @veneman.dev · 3d

And an excellent use case to use a `test.beforeAll()` => Generate playwright coverage only once, pass it to all my tests instead of generating the dataset over and over again.

Bart Veneman @veneman.dev · 3d

Okay, maybe running playwright inside vitest wasn't such a great idea. We have playwright/test for a reason 😅

2

Bart Veneman @veneman.dev · 3d

Coverage also makes very little sense if you only look at the raw data reported. So I prettify your CSS, adjust all the reported ranges for the new CSS, calculate back the missed ranges and calculate which lines are covered.
You get so much more valuable info from that.

1 2

Bart Veneman @veneman.dev · 3d

coverage seems pretty easy from the start but you get to deal with stuff like where the coverage ranges never include the `@media` part of `@media (min-width: 40em) {`. And it skips the opening and closing `{}`. So if you're looking at raw bytes you're missing a bunch of coverage.

1 1

Bart Veneman @veneman.dev · 3d

current status: running a playwright browser inside Vitest to generate CSS Coverage data on the fly. Then pass it into my function that calculates all coverage data (lines covered, per file, bytes covered, etc.) and all totals.

This thing totally rips!

Bart Veneman @veneman.dev · 6d

Of course the one thing I need to backport from Wallace to work is the one of the very few pieces that's not covered by tests. Whelp.

1 1 14

Bart Veneman @veneman.dev · 6d

excuse me sir, could you please hold off on raising the bar so much for the rest of us? 😂

3

Bart Veneman @veneman.dev · 6d

lolololol, it was re-rendering 200+ times while analyzing because I was mutating an array in a loop....

2

Bart Veneman @veneman.dev · 6d

Hehe, good one. Let's see if he can find the easter egg too 😉

1

Bart Veneman @veneman.dev · 6d

shameless plug for @projectwallace.com

www.projectwallace.com

Tried to do a bit more blogging this year as well as more opinionated tools. And perf. And a11y. And

CSS Analytics - Project Wallace

The best CSS Analyzer on the web. Check your CSS complexity, specificity, performance, design tokens and much more.

www.projectwallace.com

1 9

Bart Veneman @veneman.dev · 6d

Of course the one thing I need to backport from Wallace to work is the one of the very few pieces that's not covered by tests. Whelp.

Bart Veneman @veneman.dev · 6d

SUPER MASSIVE HONK!

1 1

Bart Veneman @veneman.dev · 7d

Looks like 3. went belly-up as well. Tried to do it without downtime but didn't work. Now transfering everything out and hoping for the best.

Project Wallace @projectwallace.com · 7d

We're experiencing some DNS issues while we're moving away from Vercel. Please hang on tight.

Fingers crossed that analyzing your CSS isn't the most important thing you were going to do today 🤞

2

Bart Veneman @veneman.dev · 7d

I went for running them in the actions runner for now. Maybe I'll revisit at some point. bsky.app/profile/vene...

Bart Veneman @veneman.dev · 7d

Running 226 playwright tests on a feature branch, including installing dependencies and downloading chromium:

- ▲ deployment: 2m56s + 56s wait for deploy to finish = 3m52s
- 🎭 playwright web server in GitHub Action: 4m56s

Quite a difference, was hoping for a little better perf here.

Bart Veneman @veneman.dev · 7d

Unfortunately it seems like a lot more work to wire up playwright tests to a deploy preview than I hoped for. My previous setup was a one liner. According to this article I'm in for a bunch of DIY. snyk.io/blog/how-to-...

Is this really the way @netlify.com? 😅

1