| FROM node:22-slim as base | |
| # Skip downloading Chromium as we are installing it manually. | |
| ENV PUPPETEER_SKIP_CHROMIUM_DOWNLOAD=true | |
| # Point Puppeteer at the manually installed executable. | |
| ENV PUPPETEER_EXECUTABLE_PATH="/usr/bin/google-chrome" | |
| # Install Google Chrome Stable and fonts | |
| # Note: this installs the necessary libs to make the browser work with Puppeteer. |
| export class PipelineStream extends TransformStream { | |
| constructor( | |
| transformStreams: Array<TransformStream>, | |
| ...strategies: Array<QueuingStrategy> | |
| ) { | |
| super({}, ...strategies) | |
| const readable = [super.readable as any, ...transformStreams].reduce( | |
| (readable, transform) => readable.pipeThrough(transform) | |
| ) |
Historically, NPM has had a number of issues that affected the entire ecosystem one way or the other. I tend to believe most of those issues arise from the fundamental design flaws of NPM and are not as easily solved.
In this document, I propose an alternative to the NPM registry. Let's call it a "Proper Package Registry", or PPR for short. This alternative aimes to solve the long-standing issues with NPM, such as name squatting, package unpublishing, versioning, as well as add a few points concerning developer experience, which is close to non-existing when using NPM as a package author.
PPR ships with a CLI that offers extensive tools to validate the package you are about to publish. This is completely missing from NPM and has been in the top of my painpoints list for all the years I've been publishing packages.
Unlike HTTP, WebSocket communication is duplex (both the client and the server can emit and listen to events) and persistent. This difference is reflected in how one would expect to mock a WebSocket communication.
I believe mocking WebSockets should be connection-based. This way each individual connected client is scoped to a particular interceptor handler.
interceptor.on('connection', (connection) => {
| async function* yieldMany(promises) { | |
| promises.forEach((p) => { | |
| return p.then((value) => { | |
| promises.splice( | |
| promises.findIndex((xp) => xp === p), | |
| 1 | |
| ); | |
| return value; | |
| }); | |
| }); |
Hi, folks. I haven’t found a human-friendly representation of what’s going on in json/base/meta/Quest/World_SecretCellar.qst.json so I spend an hour writing one up. Below is what’s described in the quest file, some of my assumptions, and a few clear things from the data I’ve not seen mentioned yet.
The quest has 3 phases:
When the objective is set (quest is taken):
WORLD_SECRETCELLAR_STATUES_ACTIVATED enum). This is not a condition so this is a side-effect (arEventFilters) and not a player requirement.
| // TODO: make `pages` optional and measure the div when unspecified, this will | |
| // allow more normal document flow and make it easier to do both mobile and | |
| // desktop. | |
| import { | |
| createContext, | |
| useCallback, | |
| useContext, | |
| useEffect, | |
| useMemo, | |
| useRef, |
This is an up-to-date guide on running Chromium in Vercel serverless functions in 2022. What you will read below is the result of two days of research, debugging, 100+ failed deployments, and a little bit of stress.
Use chrome-aws-lambda that comes with Chromium pre-configured to run in serverless, and puppeteer-core due to the smaller size of Chromium distributive.