Nice!
This is one of the things I like in DeferredPromise, too: github.com/open-draft/d...

Relying on promise state is really handy in library land, less so in userland.

Support for smaller projects is definitely appreciated! There's a big difference when there's a company behind a project and when there's one person just pushing it to the best of their ability.

I mean, destructuring isn't a mistake. It's a switch, right? If I destructure the props, they are no longer reactive. Maybe I don't want them reactive. I can have a prop like <Panel type="edit" />. It won't ever change.

If props is actually an accessor, then this makes prefect sense. Otherwise, it becomes confusing.

Playwright has an opposite limitation: the test context has to be destructured, otherwise it will throw. I wonder if that can be somehow repurposed for Solid's use case. Probably not, but worth pointing out.

The mistake I had was not knowing props are reactive and mustn't be destructured. I wonder if a warning from Solid made sense here.

The very first example made me scream "YES, this is the kind of best practices I'm talking about". Thank you for writing these!

Curious to see the actual release! I won’t base my opinion on alpha.

There is a better way in almost every library I use. There's a better way to test, better way to bundle, better way to do accessibility, better way to think about system design.

I also believe good projects should challenge the status quo time to time. Engineers have a remarkably stupid tendency in marrying to technology, whereas about each breakthrough has happened because someone stepped away from that dogma and realized there is a better way.

I always design my projects from the "perfect and down", not from "realistic and up". I don't care for realistic. I want to bring the best possible experience to my users and I am okay with paying for any limitation along the way.

I cannot stress this enough. For me, OSS is a land of opinionated visionaries. People who have battled their way into every opinion and distilled those into compact APIs that help you avoid the mistakes they've made in the past.

This is the missing piece to Playwright's authentication persistence (which this library uses under the hood). Sessions tend to go obsolete. You mustn't be storing obsolete sessions.

Management of session-dependent resources is another huge productivity boost you get in Persona.

By "platform" I am referring to the same option in tsup, specifically. The target of the build: browser, node, neutral.

Each target duplicates code for itself, but there can be only ONE entry to the module's root scope.

import { A } from 'foo'
import { B } from 'foo/browser'

If B bundled its own A, this will fail:

function accept(value: A) {}

accept(B) // ❌

Thank you, this was a great read!
I am certainly interested in anti-patterns and things I should avoid when building with Solid. Especially for folks wired into React's way of thinking.

The default behavior is that each build target will just duplicate the referenced code. Adding a shared config doesn't make those tools automatically understand "hey, maybe it's built separately so it can be shared".