Increasing Viteâs potential with the Environment API
The world continues to spin and developers spin along with it trying to find better ways to build websites. From the âjust send over HTMLâ to âsend over a JS bundle to render HTMLâ weâre now somewhere back in the middle. We have JS that runs on the server to render HTML, and JS we send to the client to handle the rest of it. Not only that, but âserverâ now is multiple runtimes with their own APIs like Bun and Deno. So you have to build a framework that can run across multiple runtimes, and has to be split to run on different computers.
How do you differentiate what should be on the server and what should be sent to the client? How can you create a codebase flexible enough to run on different environments? This was the main difficulty for many âmetaframeworks.â Not only did you have to be an expert in say React or Solid or Svelte, but you also need to be an expert on bundling and static analysis. Maybe you can create some kind of processor pragma like "use client" to help? Or a special $createServerFn() that will help you identify which swathes of code should live on the server. Regardless of how you choose to go about it, there comes a point where youâre just re-inventing the wheel if its everyoneâs problem.
In this article, Vite core-team member sapphi-red talks about how Vite went about creating a new API specifically targeting this problem of deploying code to multiple environments and splitting them across the network boundary. Iâd highly recommend reading this, as many frameworks like Remix are investing in this platform. This allows everyone in the ecosystem to move quicker, focusing on solving their own problems rather than a general issue.
https://green.sapphi.red/blog/increasing-vites-potential-with-the-environment-api
Live types in a TypeScript monorepo
If youâve worked with TypeScript monorepos before, youâve probably felt the pain of having to deal with tooling and build steps. At some point youâll make a change to the signature of a function or shape of an object in one subdirectory. Youâll quickly find that another subdirectory referencing your types will not reflect the changes made. Itâs at this point that the build step comes in. Often youâll have to run a npm run build:subdir type script which will then rebuild the type declarations and possibly a âRestart Language Serverâ command in your editor in order to get the change reflected completely.
Colin tries to address this point of friction by making some neat recommendations. Incorporating a change like getting live types in a monorepo can really boost productivity, and gets you closer to that feeling of working in a flattened repository again. If thereâs one person Iâd trust on intelligently using TypeScript, itâd be the author of Zod.
https://colinhacks.com/essays/live-types-typescript-monorepo
Conditional return type narrowing
TypeScriptâs type system always is getting cool new improvements in terms of strictness or completeness. Recently, TypeScript added a quality of life improvement around type checking function return types. Before this change, a function that contained conditional logic which could alter the return type either require you to overload its signature with multiple function declarations or write a conditional type expressing essentially your function logic again.
The writeup on the pull request does a great job of setting up the problem, and of course the proposed (now merged) solution into TypeScript. What I appreciate about this PR is how in depth the writeup is, and that itâs full of examples. If you have developers who are newer to TypeScript, they might benefit from giving this a read just to remember that TS isnât just a tool to butt heads against, but rather an elegant system of rules.