I never said it was difficult to understand, it is difficult to produce when working on something. For me, and presumably many, it's more likely to write older, less elegant syntax (hardcoded values, more classes, more media queries, etc)

While I initially ran into the problem, the deep dive was performed by @remcohaszing.nl‬, who also already made a PR for Next.js, an issue to Preact, and clarifications to TS docs 💯

github.com/preactjs/pr...
github.com/vercel/next...

First of all Uppy is removing preact/compat from its usage, as it can easily just rely on preact, to immediately resolve problems

Next.js should change from "preserve" to "react-jsx", as it actually compiles to automatic

preact/compat should not declare the React UMD namespace

Because the classic runtime (which Next.js uses) looks at the global UMD JSX type, and preact/compat also ships a global type, the two start conflicting. Even if preact/compat is a transient dependency

So who should change what?

Uppy uses Preact for it's UI components, with wrappers for all major frameworks for first-class support

We shipped some new components which import from preact/compat and suddenly Next.js apps, which use "jsx": "preserve", have thousands of JSX errors

Why this transition to automatic?

No more `import React` in every file, smaller/tree-shakable output via jsx/jsxs helpers, dev vs prod helpers (better warnings), and enables faster/leaner runtime + alternative JSX runtimes — simpler DX and better optimizations

"jsx" controls how JSX is emitted in JavaScript files

TypeScript understands 2 types of JSX runtimes. The classic runtime looks at the React.JSX namespace in the file. The automatic runtime looks at the JSX namespace exported from react/jsx-runtime or react/jsx-dev-runtime

Very nice! I recently rewrote a tus.io server work in multiple runtimes. Will take a look if there is anything useful I can steal 👀

bsky.app/profile/merl...

Releasing this soon under a new major version together with bumping the required Node.js version up from 16

In short, it means rewriting all request handlers to work with Request/Response (web API) instead of http IncomingMessage / http ServerResponse (Node.js specific) as we can turn the req/res from Node.js into the web APIs but not the other way around.

Unfortunately it's not what I mean. I don't want to manually add every node_modules folder across 25+ projects. In general I want to ignore a bunch of file extensions and folder patterns.

Oh I didn’t know. Thanks!