Forem: Okiki Ojo

Hot take: Apple v US gov't, the US gov't is right

Okiki Ojo — Fri, 05 Apr 2024 03:58:12 +0000

There seems to be a misunderstanding as to how the US gov't is using anti-competition laws in this case against Apple. I'm no legal expert but from what I've read, the core problem is Apple's various platforms allowing 3rd parties but through Market Manipulation (limited API access, stopping legal and fair products from appearing on their stores, etc...) never actually allow for free and fair competition on said Platforms and as thus is liable to be sued.

Basically you can summarize the law suit down to 2 points,

Apple is using their platform to limit competition in unfair ways; if iOS and others were not open to 3rd parties this really wouldn't be a problem
Apple may not be the largest player per-se but their Market Power and Abuse of said power is an indication of Monopolistic behaviour

Note : Gov't don't necessarily care if you're a Monopoly, what they care about is if you're actively abusing your enhanced Market Position to limit competition or promote your own products.

Another Note : The US gov't doesn't necessarily use anti-trust laws for the sake of consumers they use it to guarantee competition and a fair playground/market place with the idea being that with more competition, customers get better deals and better products

Another Another Note : The US gov't is not suing Apple for the Phones (they can't touch that since people are voting with their wallets there) they're suing Apple for their OS, and the rules being unfair on said OS

TL;DR; Apple is abusing Market Power in a way that makes it difficult to compete on their platforms. Apple may have built the best sandbox but so long as they're allowing others to play in that sandbox they need to make sure the game is played fairly, this same rule applied to Microsoft during their anti-trust lawsuit case. Windows is Microsoft's baby but if Microsoft unfairly promotes their products at the detriment to other competitors then anti-trust lawsuit (as simple as that)

Photo by Laurenz Heymann on Unsplash

From Docker to Podman - VS Code DevContainers

Okiki Ojo — Thu, 12 Oct 2023 06:58:29 +0000

Been a while... 👀

It's been a minute, hasn't it? I've been...busy, but I'm back with something that I think you'll find both useful and intriguing. While I was away, I stumbled upon a nifty trick that involves swapping Docker for Podman in DevContainers on VS Code. This isn't a step-by-step guide; it's more like sharing a cool discovery I made. So, let's get to it!

A Quick Refresher on DevContainers 🏝

If you're new to the concept, DevContainers in VS Code are a way to containerize your development environment. This ensures that your setup is both portable and consistent, effectively eliminating the "it works on my machine" syndrome.

Think of DevContainers as your very own Codespace or Gitpod, but without needing the cloud. It's like having a sandbox, but your computer is the playground. You get to build your castles in an isolated space, keeping the rest of your system pristine.

The Podman Appeal 🎸

Switching gears to Podman, why would you want to replace Docker? Imagine Docker as the old, reliable minivan. It gets the job done, but it's not the sleekest. Podman is like the electric car that just rolled off the assembly lineefficient, user-friendly, and secure.

Docker has been the go-to containerization tool for years, but Podman is emerging as a strong alternative. Podman offers a few advantages:

Rootless Containers : Run containers without needing root privileges, enhancing security. Learn more about rootless containers.
Systemd Integration : Better integration with Linux's init system, systemd. For Linux users, this is a significant benefit. Podman's compatibility with systemd offers better process management and orchestration. Learn more about systemd.
Follows Open Standards : Fully compatible with Open Container Initiative (OCI) standards. Podman is OCI-compliant, which means it adheres to industry standards for container images, making it easier to switch between different container technologies. Learn more about OCI.

So, if you're looking to break free from Docker's grasp, Podman is worth considering.

The Challenge: VS Code Loves Docker

Here's the hiccup: VS Code's DevContainers extension is tightly coupled with Docker. When you try to use Podman, VS Code throws a fit and keeps asking you to install Docker. That's the issue we're going to solve today.

The Solution: Trick VS Code with a Shell Script

macOS

Step 1: Install Podman

First things first, you'll need to install Podman. On a Mac, you can use Homebrew:

brew install podman

Step 2: Initialize and Start Podman Machine

Before using Podman, you need to initialize and start a Podman machine:

podman machine init
podman machine start

Step 3: Create a Shell Script

VS Code is looking for a command named docker. We'll give it what it wants, but we'll secretly redirect it to podman.

Create a new shell script and name it docker:

sudo nano /usr/local/bin/docker

In the script, add the following lines:

#!/bin/bash
exec podman "$@"

Save the file and exit the text editor.

Step 4: Make the Script Executable

Now, make the script executable:

sudo chmod +x /usr/local/bin/docker

Step 5: Restart VS Code

Close and reopen VS Code to apply the changes. It should now be none the wiser, happily using Podman instead of Docker.

Linux

Step 1: Install Podman

Open your terminal and run the following command to install Podman:

sudo apt install -y podman

Steps 2-5: Follow the same steps as for macOS

Windows

Step 1: Install Podman for Windows

Download and install Podman from the official site.

Step 2: Create a Batch File

Create a batch file named docker.bat to act as an alias for Podman:

@echo off
podman %*

Place this batch file in a directory that's in your system's PATH.

Option 1: Use an Existing Directory in `PATH`

Open a Command Prompt and type echo %PATH% to see the directories currently in your PATH.
Choose an existing directory that you have write access to, such as C:\Users\YourUsername\bin.
Save or move your docker.bat file into that directory.

Option 2: Create a New Directory and Add It to `PATH`

Create a new directory where you want to store your batch files, for example, C:\batch_files.
Move your docker.bat file into this new directory.
To add this directory to your PATH, right-click on 'This PC' or 'Computer' on your desktop or File Explorer, and choose Properties.
On the left-hand side, click on Advanced system settings.
Click on the Environment Variables button near the bottom right.
Under the 'System variables' section, find and select the Path variable, then click on Edit.
Click on New and add the path to your new directory, C:\batch_files.
Click OK on all the dialog boxes to save your changes.

Verify the Setup

To verify that the batch file is accessible:

Open a new Command Prompt window (important, as existing windows won't pick up the change).
Type docker and hit Enter. If everything is set up correctly, this should now execute Podman due to the aliasing in your docker.bat file.

By following these steps, you ensure that the batch file is in a directory listed in your PATH, making it accessible from any command prompt window.

Step 3: Restart VS Code

Close and reopen VS Code to apply the changes.

Wrapping Up

There you have ita Podman-powered DevContainer in VS Code, right on your local machine. It's like having a VIP pass to a more secure and efficient coding environment. Whether you're a newcomer or a seasoned developer, I hope you find this as useful as I did.

So go ahead, give Podman a spin, and bring a little more freedom to your containerized development environments.

Bye!

Originally posted on blog.okikio.dev

ESM & CJS: The subtle shift in bundlejs' behaviour

Okiki Ojo — Sat, 08 Jul 2023 07:40:48 +0000

Greetings, fellow devs and bundlejs aficionados! 🚀

I was closing out some long lived issues over on bundlejs, when issue #50 reminded me of the ongoing debate about how bundlejs should handle the ESM and CJS packages.

Lightbulbs flickered, coffee was consumed (I don't drink coffee, but you get the point), and I'm pretty sure I've cracked a solution. But there are a few slight behavior changes you need to be aware of. So buckle up. If anything looks off or confusing, please let me know in either the comments below, on GitHub Discussions or issues #50 directly.

The Issue at Hand 🧐

The root of the problem lies in how bundlejs was handling CommonJS files.

"CommonJS files only export their default, which created a conundrum. How can we tell if a module is CommonJS if we don't fetch it? And if we fetch it first, it's too late for esbuild to deal with it properly."

But never fear! I've worked out a solution that is impartial to whether the module is ESM or CommonJS.

The Solution 🧩

Let's walk through this step by step, using our handy deno.bundlejs.com API for demonstration.

Single CJS File: Only export the default (no renaming involved). Check out this example using postcss-easings: https://deno.bundlejs.com/?file&q=postcss-easings&minify=false

 // ...
 // virtual-filesystem:/index.ts
 var index_exports = {};
 __export(index_exports, {
   default: () => import_postcss_easings.default
 });
 __reExport(index_exports, __toESM(require_postcss_easings_4_0()));
 var import_postcss_easings = __toESM(require_postcss_easings_4_0());
 var export_default = import_postcss_easings.default;
 export {
   export_default as default
 };

Multiple CJS Files: Export the default but use the file URL as the import name. Also, append ...Default to the end of it like so: reactDefault & reactDomDefault. Take a peek here: https://deno.bundlejs.com/?file&q=react,react-dom&minify=false

 // ...
 // virtual-filesystem:/index.ts
 var index_exports = {};
 __export(index_exports, {
   reactDefault: () => import_react.default,
   reactDomDefault: () => import_react_dom.default
 });
 __reExport(index_exports, __toESM(require_react_18_2()));
 var import_react = __toESM(require_react_18_2());
 __reExport(index_exports, __toESM(require_react_dom_18_2()));
 var import_react_dom = __toESM(require_react_dom_18_2());
 var export_reactDefault = import_react.default;
 var export_reactDomDefault = import_react_dom.default;
 export {
   export_reactDefault as reactDefault,
   export_reactDomDefault as reactDomDefault
 };

Single ESM File: Export everything, including the default. No renaming here, folks! https://deno.bundlejs.com/?file&q=spring-easing&minify=false

 // ...
 export {
   BatchSpringEasing,
   CSSSpringEasing,
   EaseInOut,
   EaseOut,
   EaseOutIn,
   EasingDurationCache,
   EasingFunctionKeys,
   EasingFunctions,
   EasingOptions,
   FramePtsCache,
   GenerateSpringFrames,
   INFINITE_LOOP_LIMIT,
   SpringEasing,
   SpringFrame,
   SpringInFrame,
   SpringInOutFrame,
   SpringOutFrame,
   SpringOutInFrame,
   batchInterpolateComplex,
   batchInterpolateNumber,
   batchInterpolateSequence,
   batchInterpolateString,
   batchInterpolateUsingIndex,
   SpringEasing as default, // <- The default export
   getLinearSyntax,
   getOptimizedPoints,
   getSpringDuration,
   getUnit,
   interpolateComplex,
   interpolateNumber,
   interpolateSequence,
   interpolateString,
   interpolateUsingIndex,
   isNumberLike,
   limit,
   parseEasingParameters,
   ramerDouglasPeucker,
   registerEasingFunction,
   registerEasingFunctions,
   scale,
   squaredSegmentDistance,
   toAnimationFrames,
   toFixed
 };

Multiple ESM Files: Export all methods and variables from all exports, but remember to use the naming rules for all default exports. For instance, after exporting the other module exports, rename the default export to springEasingDefault and codepointIteratorDefault: https://deno.bundlejs.com/?file&q=spring-easing,codepoint-iterator&minify=false

 // ...
 var mod_default = asCodePointsIterator;
 export {
   BITS_FOR_2B,
   BITS_FOR_3B,
   BITS_FOR_4B,
   BatchSpringEasing,
   CSSSpringEasing,
   EaseInOut,
   EaseOut,
   EaseOutIn,
   EasingDurationCache,
   EasingFunctionKeys,
   EasingFunctions,
   EasingOptions,
   FramePtsCache,
   GenerateSpringFrames,
   INFINITE_LOOP_LIMIT,
   LEAD_FOR_1B,
   LEAD_FOR_2B,
   LEAD_FOR_3B,
   LEAD_FOR_4B,
   LEAD_FOR_5B,
   MASK_FOR_1B,
   MASK_FOR_2B,
   MASK_FOR_3B,
   MASK_FOR_4B,
   SpringEasing,
   SpringFrame,
   SpringInFrame,
   SpringInOutFrame,
   SpringOutFrame,
   SpringOutInFrame,
   UTF8_MAX_BYTE_LENGTH,
   asCodePointsArray,
   asCodePointsCallback,
   asCodePointsIterator,
   batchInterpolateComplex,
   batchInterpolateNumber,
   batchInterpolateSequence,
   batchInterpolateString,
   batchInterpolateUsingIndex,
   bytesToCodePoint,
   bytesToCodePointFromBuffer,
   codePointAt,
   mod_default as codepointIteratorDefault, // <- codepoint-iterator's default export
   getByteLength,
   getIterableStream,
   getLinearSyntax,
   getOptimizedPoints,
   getSpringDuration,
   getUnit,
   interpolateComplex,
   interpolateNumber,
   interpolateSequence,
   interpolateString,
   interpolateUsingIndex,
   isNumberLike,
   limit,
   parseEasingParameters,
   ramerDouglasPeucker,
   registerEasingFunction,
   registerEasingFunctions,
   scale,
   SpringEasing as springEasingDefault, // <- spring-easing's default export
   squaredSegmentDistance,
   toAnimationFrames,
   toFixed
 };

Treeshaking: Here, we assume you want the driver's seat if you add the treeshake query param to the URL. So, all of the above rules are null and void, and you now have complete control over what is exported, including the default exports not being automatic. https://deno.bundlejs.com/?file&q=spring-easing,react&treeshake=[*],[*]&minify=false

 // ...
 export {
   BatchSpringEasing,
   CSSSpringEasing,
   EaseInOut,
   EaseOut,
   EaseOutIn,
   EasingDurationCache,
   EasingFunctionKeys,
   EasingFunctions,
   EasingOptions,
   FramePtsCache,
   GenerateSpringFrames,
   INFINITE_LOOP_LIMIT,
   SpringEasing,
   SpringFrame,
   SpringInFrame,
   SpringInOutFrame,
   SpringOutFrame,
   SpringOutInFrame,
   batchInterpolateComplex,
   batchInterpolateNumber,
   batchInterpolateSequence,
   batchInterpolateString,
   batchInterpolateUsingIndex,
   getLinearSyntax,
   getOptimizedPoints,
   getSpringDuration,
   getUnit,
   interpolateComplex,
   interpolateNumber,
   interpolateSequence,
   interpolateString,
   interpolateUsingIndex,
   isNumberLike,
   limit,
   parseEasingParameters,
   ramerDouglasPeucker,
   registerEasingFunction,
   registerEasingFunctions,
   scale,
   squaredSegmentDistance,
   toAnimationFrames,
   toFixed
 };
 // ^ React isn't exported at all

🚨 Note: You might run into issues with CJS modules if you don't export default properly. Part of this is because tree-shaking is somewhat of a no-show for CJS packages, so tread lightly here!

There you have it! A quick and dirty rundown of the latest updates to the way bundlejs.com handles CJS and ESM packages.

So, go ahead and take the new system for a spin. Let me know what you think. Take it for a ride 🚗

Photo by Marcin Jozwiak: https://www.pexels.com/photo/abstract-red-and-white-waves-background-subtle-gradients-flow-liquid-lines-design-element-13835514/

Mastering the Art of ESM and CJS Package Handling

Okiki Ojo — Sat, 08 Jul 2023 07:40:48 +0000

Greetings, fellow devs and bundlejs aficionados! 🚀

I was closing out some long lived issues over on bundlejs, when issue #50 reminded me of the ongoing debate about how bundlejs should handle the ESM and CJS packages.

The Issue at Hand 🧐

The root of the problem lies in how bundlejs was handling CommonJS files.

"CommonJS files only export their default, which created a conundrum. How can we tell if a module is CommonJS if we don't fetch it? And if we fetch it first, it's too late for esbuild to deal with it properly."

But never fear! I've worked out a solution that is impartial to whether the module is ESM or CommonJS.

The Solution 🧩

Let's walk through this step by step, using our handy deno.bundlejs.com API for demonstration.

Single CJS File: Only export the default (no renaming involved). Check out this example using postcss-easings: https://deno.bundlejs.com/?file&q=postcss-easings&minify=false
Multiple CJS Files: Export the default but use the file URL as the import name. Also, append ...Default to the end of it like so: reactDefault & reactDomDefault. Take a peek here: https://deno.bundlejs.com/?file&q=react,react-dom&minify=false
Single ESM File: Export everything, including the default. No renaming here, folks! https://deno.bundlejs.com/?file&q=spring-easing&minify=false
Multiple ESM Files: Export all methods and variables from all exports, but remember to use the naming rules for all default exports. For instance, after exporting the other module exports, rename the default export to springEasingDefault and codepointIteratorDefault: https://deno.bundlejs.com/?file&q=spring-easing,codepoint-iterator&minify=false
Treeshaking: Here, we assume you want the driver's seat if you add the treeshake query param to the URL. So, all of the above rules are null and void, and you now have complete control over what is exported, including the default exports not being automatic. https://deno.bundlejs.com/?file&q=spring-easing,react&treeshake=[*],[*]&minify=false

🚨 Note: You might run into issues with CJS modules if you don't export default properly. Part of this is because tree-shaking is somewhat of a no-show for CJS packages, so tread lightly here!

There you have it! A quick and dirty rundown of the latest updates to the way bundlejs.com handles CJS and ESM packages.

So, go ahead and take the new system for a spin. Let me know what you think. Take it for a ride 🚗

Photo by Marcin Jozwiak

Originally posted on blog.okikio.dev

Vercel + Support Center = 🚀

Okiki Ojo — Tue, 07 Feb 2023 04:31:37 +0000

Support Center; my first major project at Vercel , it's been a blast working on it and it's now out. 🎉

Check it out vercel.com/changelog/support-center

BTW, I joined Vercel 🎉 ~6 months ago...

Well anyway...

Support Center is a modern tool for viewing and communicating with Customer Support at Vercel. Built for enterprises to improve the customer support experience while retaining the practices and tools that the Customer Support Team at Vercel had built up over the years. From what customers and the Customer Support Team have told us we've achieved that goal.

For some background. Before Support Center, customers had to email support before they could get any help 😬, it was clunky and prone to _" **email got sent to spam errors" _, and _" **I didn't check my email problems" _, realizing that the experience wouldn't do, the dev team drafted up the idea to connect the current Salesforce based ticketing system with a UI/UX customers would enjoy.

The main hiccup we ran into during development was the excessively complex (and archaic) work of integrating with Salesforce and the performance of the support center, of which the solution is caching (the bane of all Software Engineers everywhere).

📚 Fun fact : Salesforces uses a SQL-like syntax for querying data that's similar to SQL but yet very far away from SQL, it's called SOQL, and working with it can be very frustrating

The problems boiled down to:

How do you keep the cache always up to date?
How to keep the support center fast, responsive, and reliable with the most up-to-date info?
How to make working with Salesforce easier?

The solution to the first 2 problems... 🥁 are webhooks of course.

In essence, whenever a change is made on Salesforce we call a webhook and have that webhook sync with a cache that we use for the support cases 🤯.

We can then expand how long the cache should securely hold case data, and add a cache warm-up for when on the main page.

The last issue was dealing with the complexity of working with Salesforce, we just powered through and though frustrating, I think the results are pretty fantastic.

Working on this project was awesome, and I'm grateful for being able to work with such a capable team of designers & developers on this project.

How to upload files with Astro

Okiki Ojo — Sun, 18 Sep 2022 05:23:16 +0000

Introduction

Someone recently asked me how to use FormData with Astro, to which I responded I'll create a small document for this (I'll create a pr to add this to the Astro docs a little later).

Getting started

I won't go into detail on what FormData is, but here is a short summary

FormData [is an] interface [which] provides a way to easily construct a set of key/value pairs representing form fields and their values, which can then be easily sent using the fetch() or XMLHttpRequest.send() method. It uses the same format a form would use if the encoding type were set to "multipart/form-data". Source: MDN - FormData

Basically instead of using JSON to send data to and from your server, you'd use FormData, except unlike JSON it supports files natively.

For example,

// 1. Create or Get a File 
/** Creating a File */
const fileContent = `Text content...Lorem Ipsium`;
const buffer = new TextEncoder().encode(fileContent);
const blob = new Blob([buffer]);
const file = new File([blob], "text-file.txt", { type: "text/plain" });
/** OR */
/** Getting a File */
const fileInput = document.querySelector("#files"); // <input id="files" type="file" multiple /> 
const file = fileInput.files.item(0);

// 2. Create FormData
const formData = new FormData();

// 3. Add File to FormData through the `file` field
formData.append("file", file); // FormData keys are called fields

const file = fileInput.files.item(0);
^ fileInput.files is a FileList, which is similar but not an array, to work around this you can convert the FileList to an array of File's using Array.from

For our use case, since we're only trying to upload one file, it'd be easier to select the first File in the FileList

Learn more on MDN - HTMLInputElement and MDN - File

Note: you can also just directly use FileReader instead of using an <input /> element

Usage

There are 2 ways to support FormData in Astro; the easy and the hard way, I'll show you both.

Note : both the easy and hard way require Astro to be configured in server (SSR) mode
import { defineConfig } from 'astro/config';

// https://astro.build/config
export default defineConfig({
output: 'server',
});

Easy Way

The easy way requires you to create a new .ts file that will act as your endpoint, for example, if you wanted a /upload endpoint, you would create a .ts file in src/pages.

Read Astro's official docs on File Routes to learn more

Your basic file tree should look like this after creating your endpoint

src/
 pages/
   upload.ts
   index.astro

Inside your index.astro file follow the example I gave above in #getting-started, on getting FormData up and running.

Once you've created an instance of FormData and populated it with the files you'd like to upload, you then just setup a POST request to that endpoint.

// ...
const res = await fetch('/upload', {
  method: 'POST',
  body: formData,
});
const result = await res.json();
console.log(JSON.stringify(result));

From the endpoint side you'd then need to export a post method to handle the POST request being sent,

Here is where things get complex. I recommend going through Astro's File Routes Docs

import type { APIContext } from 'astro';

// File routes export a get() function, which gets called to generate the file.
// Return an object with `body` to save the file contents in your final build.
// If you export a post() function, you can catch post requests, and respond accordingly
export async function post({ request }: APIContext) {
  const formData = await request.formData();
  return {
    body: JSON.stringify({
      fileNames: await Promise.all(
        formData.getAll('files').map(async (file: File) => {
          return {
            webkitRelativePath: file.webkitRelativePath,
            lastModified: file.lastModified,
            name: file.name,
            size: file.size,
            type: file.type,
            buffer: {
              type: 'Buffer',
              value: Array.from(
                new Int8Array(await file.arrayBuffer()).values()
              ),
            },
          };
        })
      ),
    }),
  };
}

The basics of what's happening here are fairly simple, but the code all put together seems rather complex, so let's break it down.

First, the exported post function handles POST requests as its name suggests, meaning if you send a get request and don't export a get function an error will occur.

export async function post() { ... } what?! Yeah, I too recently learned that Astro supports this out of the box, which is awesome.

W3Schools cover POST and GET fairly well, take a look at their article if you're not familiar with POST and GET requests

Let's first talk about the request parameter. As it's name suggests request is an instance of the Request class which includes all the methods that Request supports, including a method for transforming said request into FormData you can work with.

// ...
export async function post({ request }: APIContext) {
  const formData = await request.formData();
  // ...
}

Using formData you can get all the instances of a specific field (FormData keys are called fields), for example, get all File's in the file field.

// ...
export async function post({ request }: APIContext) {
  const formData = await request.formData();
  return {
    body: JSON.stringify({
      // getAll('file') will return an array of File classes
      fileNames: formData.getAll('file'),
    }),
  };
}

The problem with this solution is that it will return {"fileNames":[{}]} due to JSON.stringify being unable to convert File classes to a string

To deal with this formatting issue we need to format the File's array properly,

// ...
export async function post({ request }: APIContext) {
  const formData = await request.formData();
  return {
    body: JSON.stringify({
      // getAll('files') will return an array of File classes
      fileNames: formData.getAll('files').map(async (file: File) => {
          return {
            webkitRelativePath: file.webkitRelativePath,
            lastModified: file.lastModified,
            name: file.name,
            size: file.size,
            type: file.type,
            buffer: { /* ... */ }
          };
        }),
    }),
  };
}

The last part is converting ArrayBuffers into data that is easy to work with, for this case using arrays to represent buffers works rather well, so we just do some conversion,

// ...
export async function post({ request }: APIContext) {
  const formData = await request.formData();
  return {
    body: JSON.stringify({
      // getAll('file') will return an array of File classes
      fileNames: formData.getAll('file').map(async (file: File) => {
          return {
            // ...
            buffer: {
              type: 'Buffer',
              value: Array.from(
                new Int8Array(
                  await file.arrayBuffer()
                ).values()
              ),
            },
          };
        }),
    }),
  };
}

That's the easy way. Using Astro's baked in file routes to act as an endpoint for your FormData.

To actually run Astro with the /upload endpoint all you need is npm run dev

You can view a demo of the easy way on Stackblitz, CodeSandbox and GitHub

codesandbox.io

Hard Way

The hard way requires you to use the multer middleware together with expressjs, in order to make the @astrojs/node integration support FormData requests.

The hard way mostly builds on the #easy-way, except instead of a src/pages/upload.ts file, you would instead use a server.mjs file in the root directory to define your endpoints, so, your file structure would look more like this,

src/
 pages/
   index.astro
server.mjs

The core of the hard way occurs inside server.mjs. server.mjs should look like this by the end of this blog post

import express from 'express';
import { handler as ssrHandler } from './dist/server/entry.mjs';
import multer from 'multer';

const app = express();
app.use(express.static('dist/client/'));
app.use(ssrHandler);

const upload = multer();
app.post('/upload', upload.array('file'), function (req, res, next) {
  // req.files is an object (String -> Array) where fieldname is the key, and the value is array of files
  //
  // e.g.
  // req.files['avatar'][0] -> File
  // req.files['gallery'] -> Array
  //
  // req.body will contain the text fields, if there were any
  console.log(req.files);
  res.json({ fileNames: req.files });
});

app.listen(8080);

When you build an Astro project in server (SSR) mode (e.g. npm run build), Astro will automatically generate a dist/server/entry.mjs file, it's this file that allows us to build our own custom nodejs server and then run Astro off this server.

For this specific use case we are using express for the server, and to enable FormData support in express we need the multer middleware, so if you're familiar with express at all this should look familiar,

import express from 'express';
import { handler as ssrHandler } from './dist/server/entry.mjs';

const app = express();
app.use(express.static('dist/client/'));
app.use(ssrHandler);

// ...
app.listen(8080);

The ssrHandler enables Astro to run on the express server, for the most part it can be treated like any other express middleware and ignored.

Note: If you're not familiar with the code snippet above, please go through express' documentation, it'll make the rest of the explanation easier to understand

The real interesting part is where multer and express meet.

By using a POST request handler we are able to recieve POST requests made to the /upload endpoint and respond back with the parsed FormData results, but unlike in the #easy-way, express is able to handle all the formatting allowing File responses to be as expected.

// ...
import multer from 'multer';

const app = express();
// ...

const upload = multer();
app.post('/upload', upload.array('files'), function (req, res, next) {
  // req.files is an object (String -> Array) where fieldname is the key, and the value is array of files
  //
  // e.g.
  // req.files['avatar'][0] -> File
  // req.files['gallery'] -> Array
  //
  // req.body will contain the text fields, if there were any
  console.log(req.files);
  res.json({ fileNames: req.files });
});

app.listen(8080);

Response to express POST request

That's the hard way. Using Astro's SSR mode together with express and multer to create the /upload endpoint which supports formData.

To actually run Astro you need to do a bit more than you'd need for the #easy-way

Install express and multer ->npm install express multer

Build Astro handler ->npm run build

Run server.mjs -> node server.mjs

The hard way may seem easier, but that is due to having done alot of the prep work in the #easy-way, it is actually more overall work than the easy way.

You can view a demo of the hard way on Stackblitz, CodeSandbox and GitHub

codesandbox.io

Conclusion

There are 2 ways of using FormData with Astro, either the easy way or the hard way.

The easy way is to use Astro's baked in File Routes to act as an endpoint for your FormData POST requests.

The hard way is to use Astro's SSR mode together with express and multer to create a /upload endpoint which supports FormData.

There is no right way, but I will recommend the easy way as it is easier and less confusing to work with overall.

Photo by Caleb Jack (@hitthetrailjack) on Unsplash.

Originally published on blog.okikio.dev

bundlejs: An online esbuild based bundler & npm package size checker

Okiki Ojo — Wed, 18 May 2022 22:18:48 +0000

Introduction
- Quick feature run down
Bundling, Treeshaking, and Minification
Console
Input and Output Tabs
Configuration
- CDN Hosts
- Compression Algorithms
- The Brotli Problem
- Default to Gzip
- LZ4, Gotta Go Fast
- Compression Quality
- Aliases and Externals
- Esbuild Config Options
Editor Buttons + Extra Features...
Drag Handles...Interactive Fun
JSX Support
Sharing Bundle Sessions
Bundle Analysis
Analytics
Discussions and Support
Security and Performance
Tips and Tricks
Contribute
Conclusion

Introduction

bundlejs (pronounced bundle js) is a quick and easy way to treeshake, bundle, minify, and compress (in either gzip or brotli) your typescript, javascript, jsx and npm projects, while receiving the total bundles' file size.

bundlejs aims to generate more accurate bundle size estimates by following the same approach that bundlers use:

Doing all bundling locally
Outputing the treeshaken bundled code
Getting the resulting bundle size

The benefits of using bundlejs are:

It's easier to debug errors
You can verify the resulting bundled code
The ability to configure your bundles
The ability to treeshake bundles
The ability view a visual analysis of bundles
You can bundle offline (so long as the module has been used before)
Supports different types of modules from varying Content Delivery Networks (CDNs), e.g. CDNs ranging from deno modules, to npm modules, to random github scripts, etc...

This blog post is meant to highlight some of the most important changes as well as to give some insight into how bundlejs works in the background, and to act as the docs for bundlejs.

📒Note: There will be a follow up article to this one, going into the technical nitty gritty on how bundlejs works and how you can use what I've learned from this project to either create your own online bundler or an es build-wasm backed js repl.

😅 TL;DR: this blog post is rather long, so take a look at the bundlejs.com website first, then skim through this blog post making sure to check out the images and the code examples, those can help cut down on confusion and reduce the required reading time.

Quick feature run down

This video runs through all the major features of bundlejs (there is audio but I don't have a good mic 😅)

Bundling, Treeshaking, and Minification

Bundling is the process of efficiently concatenating modules together into one file which we call a bundle.

Treeshaking is the process of a bundler traversing the modules to be bundled and removing unused code.

Minification is the process of shrinking the amount of code necessary to have a functional program, e.g. removing blank space or reducing variable names, etc...

bundlejs uses esbuild and it's incredible ability to bundle, transform, transpile, minify, treeshake and traverse files. Specifically, bundlejs uses esbuild-wasm which is able to access a subset of those features, with the key limitations being,

npm only runs on node, so no package.json or npm install (a-la, a joke about using StackBlitz WebContainers to run node on the browser)
browsers don't work the way nodejs does. They don't have a easy way to access file system, so storing and accessing files isn't practical. The way esbuild would normally work when installed on node just causes issues on the web
due to the limitation of esbuild-wasm when running on a browser (no npm, and node nodejs), the only option is for modules to come from the web but esbuild doesn't natively support importing http(s)://... modules, so a different solution is required

To solve each of these problems esbuild's plugin system comes in clutch. I created a total of 4 plugins to solve these limitations, they are,

HTTP plugin - Fetches and caches modules
CDN plugin - Redirects npm package imports (sometimes referred to as bare imports) to Content Delivery Network (CDN) urls for fetching
EXTERNALS plugin - Marks certain imports/exports as modules to exclude from bundling
ALIAS plugin - Aliases certain imports/exports to modules of a different name

Content Delivery Networks (CDNs) are a great way to distribute code all over the world at fast speeds. In the context of bundlejs, CDNs represent online repositories of code that bundlejs can fetch from.

For example, unpkg.com is a fast global content delivery network for everything on npm. It's used to quickly and easily load any file from any package on npm using a URL like: https://unpkg.com/package-name@version/file.js, a similar thing would apply for skypack.dev, esm.sh, etc...

In a later blog post I will delve deeper into the technical details of how these plugins work, but for now just keep in mind that these plugins assist esbuild-wasm to create javascript bundles.

View the impact of treeshaking on bundle size.

ℹ️ Info: This is the impact treeshaking and minifying a bundle has on bundle size,

treeshaken

vs.

non-treeshaken

Console

In previous versions of bundlejs.com I encouraged devs to use the devtools console for viewing console logs, and for a while I thought it was an ok experience, but I started realizing that it was inconvenient and not very mobile friendly. Initially, I thought creating a virtual console would be a large undertaking, so I delayed adding a custom console for quite some time. Well in the March of this year inspired by @hyrious's esbuild-repl I finally did it 👏.

Console Results

The console functions by listing out details of the build pertinent to users e.g. fetched packages, errors, etc... This includes bundle result info. e.g.

Fetching Packages

By default the console will display the progress for fetching packages, it's often the best way to diagnose errors and issues, as well as to find points of improvement.

For some packages (ahem @babel/core) there are too many sub-packages. Having the virtual console handle that many logs will eat up too much memory and/or slow down less powerful devices, so I limit the number of logs to 250 and when that limit is passed bundlejs will show this friendly message,

📒 Note: you can still access the full console log from the devtools console, even if the virtual console does any kind of truncating.

You can change the maximum amount of logs allowed in the config via,
{
    "esbuild": {
        "logLimit": 500
    }
}

Console Errors & Warnings

Errors look like this

Warnings look like this

Console Buttons

The consoles were also given buttons to make them easier to navigate, they are these right here

This is the scroll to top button. As new console logs are introduced, the console automatically sticks to the bottom, some users may find this behavior annoying so this button offers a quick and easy opt out, by taking the user straight to the top of the console.
This is the scroll to bottom button. Basically a get to the bottom as quick as possible button, it's meant for quickly checking out the final bundle result.
This is the expand/collapse button, it expands/collapses all errors and warnings quickly, making it easier to navigate through a large set of errors.
This is the clear console button, it clears the console of contents leaving the console looking like this,

Console Extras

Sticky Console: Sticks console scroll position to the bottom, for new logs. If you scroll ~50px away from the bottom this behavior no longer applies, if you scroll back to the bottom the behavior will apply again.

Pet-peeve alignment: I get so annoyed when things that can align don't align, so I built into the console to align by default with the bundlejs result section on large enough screen, e.g. laptops, tablets, desktops, etc...

Clickable console links: Exactly as it sounds, clickable console links highlight urls that start with http(s)://..., they function just like how vscode and the devtools does, and act as an easy way to access console urls without having to copy and paste the url manually.

It does have some limitations, namely it sometimes has difficulty recognizing which characters are links and which are not, e.g.

I couldn't find an example while making this blog post 🤣, when/if (hoping it's an if rather than a when) I find one I'll update this post.

Log bundle results: The bundle results, e.g. the time it takes to create the bundle, the initial bundle size, the compressed bundle size and more, are logged to the console.

Input and Output Tabs

With the addition of the console I wanted to ensure that the editors weren't unwieldy, so I created a tab bar for the input, output and config editor. The tab bar allows for quick access to all editors while ensuring that the console is always available.

Configuration

In v0.2 I added support for custom configurations (configs), it supports most of esbuild's build options, as well as some added options to change the default CDN and the compression algorithm.

The default config is
{
  "cdn": "https://unpkg.com",
  "compression": "gzip",
  "esbuild": {
      "target": [ "esnext"],
      "format": "esm",
      "bundle": true,
      "minify": true,
      "treeShaking": true,
      "platform": "browser"
  }
}
When you click the share button, it will also share the custom config you've setup, e.g.
{
  "cdn": "https://unpkg.com",
  "compression": "lz4",
  "esbuild": {
      "target": [ "es2018" ],
      ...
  }
}
The config above would result in this share URL bundlejs.com/?q=@okikio/animate&config={"compression":"lz4","esbuild":{"target":["es2018"]}}.

Notice how cdn is missing from the share URL, that's because bundlejs smartly decides on which config to send as a part of the share URL based on how different the new config is from the default config.

📒 Note: There are 3 available compression algorithms, brotli, gzip, and lz4.

CDN Hosts

Content Delivery Networks (CDNs) are a great way to distribute code all over the world at fast speeds. In the context of bundlejs, CDNs represent online repositories of code that bundlejs can fetch from.

For example, unpkg.com is a fast global content delivery network for everything on npm. It's used to quickly and easily load any file from any package on npm using a URL like: https://unpkg.com/package-name@version/file.js, a similar thing would apply for skypack.dev, esm.sh, etc...

By default bundlejs lets you enter code like this,

export * from "@okikio/animate";

But behind the scenes bundlejs auto fetches that specific package from a CDN namely, unpkg.

In older versions of bundlejs the default CDN used to be skypack but because skypack doesn't have easy access to the package.json of node packages, I switched to using unpkg as the default CDN.

With later updates bundlejs recieved the ability to update the default cdn on a global or local scale.

Technical details and more info...

You can choose CDNs by,

(Global CDN) Setting the CDN config to a different CDN host, e.g.

{
    "cdn": "https://cdn.esm.sh",
    // OR
    "cdn": "skypack"
}

(Local CDN) Using the CDN host as an inline url scheme, e.g.

export { animate } from "skypack:@okikio/animate"; 
//                       ^^^^^^^  https://cdn.skypack.dev/@okikio/animate

There are a total of 8 supported inline CDN host url schemes:

*   `skypack:react` -> [https://cdn.skypack.dev/react](https://cdn.skypack.dev/react)

*   `unpkg:react` -> [https://unpkg.com/react](https://unpkg.com/react)

*   `esm.sh:react` or `esm:react` -> [https://cdn.esm.sh/react](https://cdn.esm.sh/react)

*   `deno:preact` -> [https://deno.land/x/preact](https://deno.land/x/preact)

*   `esm.run:react` -> [https://esm.run/react](https://esm.run/react)

*   `github:facebook/react/main/packages/react/index.js` -> [https://raw.githubusercontent.com/facebook/react/main/packages/react/index.js](https://raw.githubusercontent.com/facebook/react/main/packages/react/index.js)

*   `jsdelivr:react` -> [https://cdn.jsdelivr.net/npm/react](https://cdn.jsdelivr.net/npm/react)

*   `jsdelivr.gh:facebook/react/packages/react-dom/index.js` -> [https://cdn.jsdelivr.net/gh/facebook/react/packages/react-dom/index.js](https://cdn.jsdelivr.net/gh/facebook/react/packages/react-dom/index.js)

After determining the CDN to use, the next step is to determine if the CDN host supports npm style modules, examples of which are unpkg, skypack, esm.sh, etc...

The factors involved in determining that a CDN host supports npm style modules are that the CDN hosts supports:

The CDN supports package versioning through the @version URL tag (e.g. react@18).
The CDN can load a node packages, package.json file.

📒 Note: Without the package.json you can't load subpath imports, plus it becomes more difficult to determine the correct exported modules to bundle with.

⚠️ Warning: If the chosen CDN doesn't support the package.json file and it isn't a npm style CDN host, then bundlejs will switch to trying to guess package versions, this may lead to inaccurate bundles with the wrong versions of packages.

In a later blog post I will delve deeper into the technical details of how the esbuild CDN plugin works to determine which CDN host to use, but for now you just keep in mind that the CDN plugins assist esbuild-wasm in resolving CDN host urls.

Compression Algorithms

bundlejs offers the options of bundling using:

brotli - results in the smallest bundle size but it's the slowest
gzip - results in the 2nd smallest bundle size but it's faster than brotli (default)
lz4 - results in the largest bundle size but it's the fastest bundle algorithm

📒 Note: Each compression algorithm has it's own story.

The Brotli Problem

brotli is a compression algorithm that compresses data really well, however, it's very slow compared to other alternatives. Adding brotli was quite an undertaking with lots of ups and downs, but thanks to Lewis Liu on Twitter I was able to use deno-brotli to include a WASM version of brotli in bundlejs.

Learn the story behind brotli support...

No shade to the original creators of brotli-wasm and wasm-brotli (different packages, similar name) but the way both packages handle WASM forces devs to use webpack (which wasn't happening, I value my time tooooo much for that), after multiple attempts and 6 months of work later I finally found deno-brotli.

An example of the way WASM is used in both packages (brotli-wasm and wasm-brotli) is as follows,
import WASM from "./bg.wasm";
// ...
In all honesty, it's not fair for me to blame the creators of brotli-wasm and wasm-brotli, it's not their fault. The fault lies in the js ecosystem not yet finding an interoperable solution for working with WASM. That's one of the key reasons I'm very thankful for Lewis Liu pointing out deno-brotli.

deno-brotli does 2 things right, they are,

It compresses the huge WASM file required for deno-brotli into an lz4 compressed string, which can then be decompressed by lz4 allowing for easy storage of the WASM as a js file (the result is great build tools support as the WASM is just a string inside a JS file, plus it solves the ecosystem problem really well).

For lz4 support bundlejs is using deno-lz4, which also runs via WASM, but the way deno-lz4 compress itself is slightly different than deno-brotli. I'd highly encourage you to take a look at the source code for deno-lz4 it's really informative.
By having the WASM as a js file you can actually preload the WASM as a js module 🤯

You can read through this tweet thread to learn more,

// Detect dark theme var iframe = document.getElementById('tweet-1498898909879422977-365'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1498898909879422977&theme=dark" }

Default to Gzip

bundlejs has used gzip as the default for quite sometime, bundlejs used to use pako, but thanks to a discussion with @matthewcp who rightfully pointed out the (De)compression Stream API, I started looking into alternative to pako.

// Detect dark theme var iframe = document.getElementById('tweet-1503704061853450242-596'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1503704061853450242&theme=dark" }

Learn the story behind gzip support...

Thanks to the conversation with @matthewcp, I actually did some further research into pako alternatives, I have 3 possible alternatives, they are denoflate (which uses WASM), deno-compress (which uses js), and CompressionStream (which is built into browsers), yay fun 🎉😅.

I eventually chose to replace pako with denoflate as the default compression algorithm for gzip, it's a bit faster and smaller than pako.

LZ4, Gotta Go Fast

In order to use WASM in a portable way, deno-brotli would compress the WASM binary file into a base64 string using lz4 as the compression algorithm. I saw the oppertunity to add another compression algorithm, so I used the lz4 (deno-lz4) implementation used to compress the brotli WASM binary string (see #the-brotli-problem for more info.), it was by far the easiest compression algorithm to add to bundlejs 🤣.

Compression Quality

You can set the quality of the compression (from a scale of 1 to 11, with 1 being the least compressed and 11 being the most compressed), you can set the compression quality for any of the compression algorithms mentioned above by setting the compression config option to,

{
    "compression": {
        "type": "brotli",
        "quality": 11
    }
}

You can check out a demo here, bundlejs.com/?config={"compression":{"type":"brotli","quality":11}}.

Aliases and Externals

Aliases are a way to redirect certain packages to other packages, e.g. redirecting the fs to memfs, because fs isn't supported on the web, etc... This wasn't a direct feature request but I felt it would be a good addition.

Externals are a direct feature request issue#13, it took a while but a good solution is finally a part of bundlejs, you use it the way you'd use the esbuild externals config option.

More details...

You use aliases it like this,

{
    "alias": {
        "@okikio/animate": "@babel/core"
    }
}

You can try it out below, bundlejs.com/?config={"alias":{"@okikio/animate":"@babel/core"}}.

You use externals like this,

{
    "esbuild": {
        "external": ["@okikio/animate"]
    }
}

You can try it out below, bundlejs.com/?config={"esbuild":{"external":["@okikio/animate"]}}.

Check out a complex example of using the external config bundlejs.com/?q=@babel/core&config={"esbuild":{"external":[...]}}

No one else can understand my pain...I'm adding more feature to bundlejs as I'm writing this blog post, so it's just getting longer and longer and longer, etc.... 😅

Esbuild Config Options

esbuild config options are exactly how they sound, however, with esbuild running on the browser there are some limitations on what esbuild can do, due to the lack of native filesystem access some options don't work or are rendered obsolete.

The supported esbuild build options are

Simple options

Advanced options

Quite a bit to work with I'd say.

Editor Buttons + Extra Features...

The editor buttons add extra functionality to the editor, they enable easy access to common editor tasks.

The current list of editor buttons are:

Editor panel toggle

Toggles on or off the editor buttons, leaving more space for the code editor. It looks like this when the editor buttons are hidden,

Clear editor button

Clears the editor of all its contents.

Format code button

Cleans up any messy code it finds. It uses dprint to format the input and output editor code, but falls back to monaco-editors baked in formatter for the config editor.

Reset code button

Resets the editor to it's initial state.

For the input editor, it resets it to this,

// Click Build for the bundled, minified and compressed package size
export * from "@okikio/animate";

For the output editor, it resets it to this,
```
// Output
```

For the config editor, it resets it to this,

{
    "cdn": "https://unpkg.com",
    "compression": "gzip",
    "analysis": false,
    "esbuild": {
        "target": [
            "esnext"
        ],
        "format": "esm",
        "bundle": true,
        "minify": true,
        "treeShaking": true,
        "platform": "browser"
    }
}

Copy code button

Copies the editors code, it's exactly as it sounds (what were you expecting? 🤣). When you copy code from the editor using the copy button, this delightful little message appears,

Wrap code button

Toggles between wrapped and unwrapped code. Wrapping is all about making the editors code wrap around the constraints of the editors bounding box, removing the need to scroll horizontally to view all the code.

This is how wrapped code looks,

This is how unwrapped code looks,

Bonus features

Bonus: You can access monaco's built in command palette by pressing F1, e.g.

Extra Bonus: You can use many of the code shortcuts vscode has by just right clicking while in focus on the monaco-editor, e.g.

Drag Handles...Interactive Fun

The new drag handles enable a more interactive experience with the editor, they are a little like the drag handles in vscode, but mobile friendly.

bundlejs being mobile friendly isn't a huge focus point for the project, but it's nice to have if you ever find yourself in the need for bundlejs while on a mobile or touch enabled device.

JSX Support

JSX is now officially supported in bundlejs 🎉.

Ignore the red error lines, for some reason the monaco code editor doesn't want to work well with JSX 😅

To use JSX you need to set the jsxFactory and the jsxFragment config options according to the JSX based framework you are using.

e.g. for Preact the following config would be used:

{
    "esbuild": {
        "jsxFactory": "h",
        "jsxFragment": "Fragment"
    }
}

Try out the preact demo

Sharing Bundle Sessions

To share bundle sessions* between multiple users (while avoiding the need for a server) we need a static and local way to store and share code between users. To solve this problem I decided to encode the bundle session* information right into the URL, this was because I wanted the entire project to run offline, and I didn't want the high maintenance cost of a server and database.

*sessions are the specific state of bundlejs at a specific time, they are not the entire bundle session history, just the input code and the bundle configuration at the time the share button is clicked.

Technical details...

A high-level summary of how this works is that users make a change in the input code editor, that change then gets saved and encoded into the URL. The URL can then be used to create replays of the bundle session.

A sample session url is,

/?q=(import)@okikio/emitter,(import)@okikio/animate,(import)@okikio/animate,(import)@okikio/animate,(import)@okikio/animate,@okikio/animate,@okikio/animate,@okikio/animate,@okikio/animate&treeshake=[T],[{ animate }],[{ animate as B }],[ as TR],[{ type animate }],[],[{ animate as A }],[ as PR],[{ animate }]&text="export  as PR18 from \"@okikio/animate\";\nexport { animate as animate2 } from \"@okikio/animate\";"&share=MYewdgziA2CmB00QHMAUAiAwiG6CUQA&config={"cdn":"skypack","compression":"brotli","esbuild":{"format":"cjs","minify":false,"treeShaking":false}}&bundle

The resulting input code of this bundle session url is this,

// Click Build for the Bundled, Minified & Compressed package size
import T from "@okikio/emitter";
import { animate } from "@okikio/animate";
import { animate as B } from "@okikio/animate";
import  as TR from "@okikio/animate";
import { type animate } from "@okikio/animate";
export  from "@okikio/animate";
export { animate as A } from "@okikio/animate";
export  as PR from "@okikio/animate";
export { animate } from "@okikio/animate";
console.log("Cool")
export  as PR18 from "@okikio/animate";
export { animate as animate2 } from "@okikio/animate";

with a config of,

{
    "cdn": "skypack",
    "compression": "brotli",
    "esbuild": {
        "target": ["esnext"],
        "format": "cjs",
        "bundle": true,
        "minify": false,
        "treeShaking": false,
        "platform": "browser"
    }
}

The URL breakdown is,

/?
q=(import)@okikio/emitter,(import)@okikio/animate,(import)@okikio/animate,(import)@okikio/animate,(import)@okikio/animate,@okikio/animate,@okikio/animate,@okikio/animate,@okikio/animate&
treeshake=[T],[{ animate }],[{ animate as B }],[* as TR],[{ type animate }],[*],[{ animate as A }],[* as PR],[{ animate }]&
text="export * as PR18 from \"@okikio/animate\";\nexport { animate as animate2 } from \"@okikio/animate\";"&
share=MYewdgziA2CmB00QHMAUAiAwiG6CUQA&
config={"cdn":"skypack","compression":"brotli","esbuild":{"format":"cjs","minify":false,"treeShaking":false}}&
bundle

q or query represents the module, e.g. react, vue, etc...

You can add (import) in-front of a specific module to make it an import instead of an export
treeshake represents the export/imports to treeshake.

The treeshake syntax allows for specifying multiple exports per package, through this syntax
```
"[{ x,y,z }],[*],[* as X],[{ type xyz }]" 
// to
export { x, y, z } from "...";
export * from "...";
export * as X from "...";
export { type xyz } from "...";
```
The square brackets represent seperate packages, and everything inside the squarebrackets, are the exported methods, types, etc...
text represents the input code as a string (it's used for short input code)
share represents compressed string version of the input code (it's used for large input code)
config represents the bundle configuration to use when building the bundle
bundle tells bundlejs to bundle the input code on start-up. This isn't on by default for security reasons. I want to discourage people from sending large complex bundles that crash browsers or that take a long time to load, especially before the input code is properly verified as non-malicious. So, if you want to bundle the code on startup, you have to manually add &bundle to the end of the url yourself.

The reason why I decided on this syntax is because it allows for a lot of flexibility, and transparency concerning what is being bundled. I also wanted to make it easy to share bundle session between users.

Bundle Analysis

bundlejs can analyze and visually represent bundles as easy to navigate and easy to understand charts.

Using a port of esbuild-visualizer and rollup-plugin-visualizer by @bardadymchik I added the ability to visualize bundles, this feature comes from a feature request by @atomiks on issue#22, the issue is still open you can make suggestions to improve this feature.

The bundle analysis charts are displayed right under the editor, like so,

The charts displayed comes in 3 distinct flavours:

Treemap Chart

Treemap charts are the most memorable form of bundle analysis chart, the inspiration behind this chart is webpack-bundle-analyzer. webpack-bundle-analyzer is the progenitor of bundle analyzers, and a great inspiration to the approach bundlejs took to creating charts.

Treemap charts,

Help you realize what's really inside your bundle,

Find out what modules make up the most of its size

Find modules that got there by mistake

Optimize it!

Source: github.com/webpack-contrib/webpack-bundle-analyzer

Source: github.com/webpack-contrib/webpack-bundle-analyzer

Though, the bundlejs treemap chart is less powerful than the webpack-bundle-analyzer's treemap chart, it is simpler, and faster to use, (bundlejs uses esbuild and the bundle analysis is easily available online).

Network Chart

Network charts don't change a lot from the treemap chart, however, they do offer a unique perspective on the impact of the relative sizes of modules in a bundle.

Sunburst Chart

Similar to network charts, sunburst charts don't reinvent the wheel, they accomplish similar things to the treemap chart, though the difference comes in how they represent the relative size of modules in bundles.

Sunburst charts use pie charts to represent bundle sizes, it aids in understanding just how much of the total bundle size certain modules take up.

Technical details...

📒 Note: All analysis charts support the gzipped and brotli compressed sizes of bundles! When analyzing a bundle it will choose either gzip or brotli based on the compression type.

e.g. A config of,
{ 
  "compression": "gzip" 
}
will use gzip compression for the charts, resulting in,

Analytics

When I initially built the project I only used a simple page view counter, I wanted to view how popular the project was without violating user privacy, it worked but I felt it could be better, so I decided to also use umami as a privacy preserving, cookieless, open source, Google Analytics alternative, to which the analytics are public for anyone to view.

Extra details...

For bundlejs a self-hosted version of umami is used, this is to ensure user data is kept private and secure. When trying to setup the self-hosted version of umami, I found that the article Setting up Umami with Vercel and Supabase by Jakob Bouchard, was a great help.

The analytics are publicly available, check them out at, analytics.bundlejs.com/share/bPZELB4V/bundle

Or click the page visit counter

📒Note: bundlejs is still using a page view counter, the view counter is powered by countapi (to the best of my knowledge countapi is now deprecated, however, the servers for the project are still up and running so I'll keep using the project until I switch to using umami for page views as well as general analytics).

Setting up Umami with Vercel and Supabase

Jakob Bouchard ・ Feb 2 '21

#analytics #firstpost #webdev #tutorial

Discussions and Support

To encourage discussion, give support and to gain feedback, I added a comment section to bundlejs, I used giscus for this.

Initialy, when I created the bundlejs project I also created a GitHub Discussion for it as well. I didn't want to have the overhead of having to manage a Discord server, so I choose GitHub Discussions for chats about bundlejs. The problem is that no one really uses GitHub Discussions, so I to integrated it right into the website itself via giscus, this was so new users can easily interact with others, get support from me, and leave me feedback.

Technical details...

giscus is an open-source comments system powered by GitHub Discussions, it lets visitors leave comments and reactions on your website via GitHub! It was heavily inspired by utterances.

For bundlejs I'm using a self-hosted version of giscus, this was for security reasons mostly. When trying to setup giscus for bundlejs, the self-hosting docs on the GitHub repo are very helpful, I highly suggest anyone thinking of using giscus read it, it gives insight into how giscus works on the backend.

You can check out the integrated giscus comments under the link, bundlejs.com/#discus.

As of right now the comments section is looking really bare and basic, why not leave your mark. Leave a comment with what you love and what you think needs improvement in bundlejs, I'll go through them and try to integrate your ideas into bundlejs.

Security and Performance

Security and performance are critical quality areas for bundlejs. In order to bundle modules together, bundlejs has to fetch multiple sets of modules from all over the internet, while ensuring that malicious actors don't get involved, and that esbuild-wasm isn't taken advantage of to crash other devices.

Some really...really large modules can take up to 4+ GB of memory to be bundled properly by esbuild-wasm.

The security criterias I set for bundlejs were:

Don't leak personal user info.
Don't go through a central server, e.g. the ability to get node modules from various sources
Ensure people always know what packages they are bundling
Ensure people can't use bundlejs to maliciously slowdown browsers

To ensure I met the security criterias set,

I use strict Content Security Policies (CSP) for bundlejs, ensuring no unintended 3rd party can get involved.
I self-host as many of the 3rd party scripts I can. By enclosing the number of hands involved in bundlejs.com I reduce the chance that personal information is leaked.
I use sandboxing techniques e.g. Web Workers and Shared Workers to ensure the main thread runs at a smooth 60fps while avoiding access to the DOM.

Web Workers and Shared Workers are scripts that run on a seperate thread, by using Workers I am able to isolate potentially malicious code while ensuring that the main-thread isn't affected.

Most of the uses of Workers were Shared Workers. Shared Workers reduce the performance impact of multiple instances of the bundlejs site/web app running on the same device.
To reduce the chance of bundlejs being used to maliciously slowdown browsers, I ensure the share URL is easy to read and understand, and by default disable auto-bundling for shared URLs.

The current browser landscape for Shared Worker support is spotty at best.

The support table looks like this,

Browser	Shared Workers	Module Workers
Firefox	Yes	No
Chrome	Yes	Yes
Safari	Yes*	Yes

* Support for Safari is currently experimental, but should be coming in later versions

Module Workers are esmodules that run in Workers.

📒 Note: I built a Shared Worker polyfill @okikio/sharedworker. It's a small but simple polyfill that falls back to a regular Web Worker if Shared Workers are not supported. You can use it while waiting for the next version of Safari to support Shared Workers, or while supporting older versions of Safari.

⚠️ Warning: The Shared Worker polyfill doesn't handle module workers, you will still need to somehow compile your modules to non-esm versions to support workers in Firefox. You can view how bundlejs handles module workers in the bundlejs source code, you may also wish to view the astro-repl source code to see how it handles module workers.

Most of the other security policies are passive in nature, e.g.

bundlejs only bundling on page load if the URL has ?bundle in it.
bundlejs enforcing https:// for all requests, including for iframes, etc...
Only have properly vetted CDN hosts for bundlejs by default.
etc...

Tips and Tricks

Top tier tip, follow me (@okikio_dev) and bundlejs (@jsbundle) on twitter; shameless plug 🤣.

I do post announcments and updates on these accounts, as well as small tips and tricks that help in making the most use of bundlejs.

When bundling packages that also export CSS and other external files, bundlejs.com now checks the gzip/brotli size of these external files, however, it won't output the external files' code, this behaviour may change in the future but for now that is the approach I am going with. Keep this in mind this isn't a bug, however, if it causes confusion I am willing to change this behaviour.
Treeshaking is available, but not all CDNs support access to each packages package.json so there might be slight package version conflicts. The only verified CDN with access to the package.json is https://unpkg.com. The other CDN's that are used either pre-bundle the code for us (this is hit or miss depending on the package) or they aren't full npm CDN's e.g. https://deno.land or https://raw.githubusercontent.com.
Check the full devtools console for error messages and warnings, if you are having trouble debuging an issue in bundlejs, or even better yet enable esbuilds verbose logging when trying to debug issues, e.g.
```
{
    "esbuild": {
        "logLevel": "verbose"
    }
}
```
Check out a demo.
You can use custom protocols to specify which CDN's specific imports/exports module should use. If an error occurs such that you can't bundle a package properly, I highly suggest switching CDN's via either custom protocols or by changing the cdn config option. I recommend using custom protocols instead of the cdn config option when trying to debug issues with a CDN:

e.g.
```
{
    "cdn": "unpkg"
}
```
or
```
export * from "unpkg:typescript";
```
Try using custom protocols to solve this example issue on bundlejs.
For some packages a soft error occurs where the default export is excluded from the treeshaken bundle, the solution for this is to manually include the default export like so,
```
export * from "skypack:solid-dismiss";
// and
export { default } from "skypack:solid-dismiss";
```

If you have a tip and trick you would like to share, post a comment below, or send me a tweet!

Contribute

The codebase is currently quite disorganized so, I'd suggest direct messaging me on Twitter or starting a GitHub Discussion to discuss ways to contribute.

There is a lot of stuff happening on the bundlejs project and it can be very overwhelming, if you think you can still contribute by all means please do! I will eventually get to writing detailed docs, on how to contribute, and how everything works in the backend, look forward to it.

You can use a pre-made Gitpod dev environment to quickly get started with the project or to contribute quick changes to the project.

If you love the project, I'd welcome if you'd spread the word, my goal is to make bundlejs a viable alternative/replacement for bundlephobia and even local bundlers, but right now the project is so small that most people who'd benefit from it don't know about it. I'd love to see people using it.

Last note, bundlejs is now on OpenCollective, so if you'd like to contribute to it financially, it'd be appreciated.

Conclusion

bundlejs, a quick and easy way to treeshake, bundle, minify, and compress (in either gzip or brotli) your typescript, javascript, jsx and npm projects, while receiving the total bundles' file size.

bundlejs aims to generate more accurate bundle size estimates by following the same approach that bundlers use:

Doing all bundling locally
Outputing the treeshaken bundled code
Getting the resulting bundle size

The benefits of using bundlejs are:

It's easier to debug errors
You can verify the resulting bundled code
The ability to configure your bundles
The ability to treeshake bundles
The ability to view a visual analysis of bundles
You can bundle offline (so long as the module has been used before)
Supports different types of modules from varying Content Delivery Networks (CDNs), e.g. CDNs ranging from deno modules, to npm modules, to random github scripts, etc...

The next time you need to bundle a project or you need to know the bundle size of a project, give bundlejs.com a try.

📒Note: There will be a follow up article to this one, going into the technical nitty gritty on how bundlejs works and how you can use what I've learned from this project to either create your own online bundler or an esbuild-wasm backed js repl.

Photo by Okiki Ojo, you can find the image on Dropbox.

Originally published on blog.okikio.dev

Also, published on Hackernoon and dev.to

@okikio/sharedworker, SharedWorkers on all browsers

Okiki Ojo — Fri, 15 Oct 2021 22:49:14 +0000

For bundlejs.com, and astro.build/play, I found that I needed a way to use SharedWorkers reliably on all browsers, so, I decided to make a miniature script that would act as a wrapper around the SharedWorker class, by default it would try to create a SharedWorker but otherwise would switch to normal web workers this made SharedWorkers a type of progressive enhancement.

When I realized that a polyfill/ponyfill doesn't exist for SharedWorkers I realized I needed to make one, and to ensure reliable that the polyfill was thoroughly vetted and tested for cross browser compatibility, so, I made @okikio/sharedworker.

okikio / sharedworker

A small spec. compliant polyfill for SharedWorkers, it acts as a drop in replacement for normal Workers.

@okikio/sharedworker

NPM | Github | Docs | Licence

A small mostly spec. compliant polyfill/ponyfill for SharedWorkers, it acts as a drop in replacement for normal Workers, and supports a similar API surface that matches normal Workers.

Ponyfills are seperate modules that are included to replicate the functionality of the original API, but are not required to be used.

Polyfills update the original API on the global scope if it isn't supported in that specific environment or it's feature set is lacking compared to modern variations.

Check out the blog post, created for it's launch.

Installation

npm install @okikio/sharedworker

Others

yarn add @okikio/sharedworker

pnpm install @okikio/sharedworker

Usage

import { SharedWorkerPolyfill as SharedWorker } from "@okikio/sharedworker";
// or 
import SharedWorker from "@okikio/sharedworker";

You can also use it directly through a script tag:

<script src="https://unpkg.com/@okikio/sharedworker"></script>
<script type

…

View on GitHub

Usage

@okikio/sharedworker is a small mostly spec. compliant polyfill/ponyfill for SharedWorkers, it acts as a drop in replacement for normal Workers, and supports a similar API surface that matches normal Workers.

You use it like this,

shared-worker.js

/* 
 * All variables and values outside the `start(...)` function are shared between all pages, this behavior can cause unexpected bugs if you're not careful
 */
const start = (port) => {
    // All your normal Worker and SharedWorker stuff should just work
    // With no more setup 

    /** 
     * All variables and values inside the `start(...)` function are isolated to each page, and will be allocated seperately per page. 
     */
    port.onmessage = ({ data }) => {
        if (data == "Hey")
            port.postMessage("Hello, from the SharedWorker."); 
    };
};

self.onconnect = e => {
    let [port] = e.ports;
    start(port);
};

// This is the fallback, just in case the browser doesn't support SharedWorkers
if ("SharedWorkerGlobalScope" in self) 
    start(self);

main.js

import SharedWorker from "@okikio/sharedworker";

const sharedworker = new SharedWorker(new URL("shared-worker.js", import.meta.url));
sharedworker.onmessage = ({ data }) => {
    console.log(data); //= Hello, from SharedWorker
};

sharedworker.postMessage("Hey");

In the cases of bundlejs.com and astro.build/play, @okikio/sharedworker was used for esbuild as well as the monaco-editors editor and typescript workers.

Limitation

The major limitation with @okikio/sharedworker is that on browsers that don't support SharedWorker, you can't use @okikio/sharedworker as a cross tab, communication tool. But for everything else it's feature parity and spec. compliance should be great.

Conclusion

So, will you use it? Tell me below, or say Hi on twitter.

// Detect dark theme var iframe = document.getElementById('tweet-1449083583684124679-488'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1449083583684124679&theme=dark" }

Image from Tengyart on Unsplash.

Major updates for bundlejs.com v0.0.3

Okiki Ojo — Mon, 20 Sep 2021 05:46:54 +0000

// Detect dark theme var iframe = document.getElementById('tweet-1439825148769619972-215'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1439825148769619972&theme=dark" }

I released major updates for https://bundlejs.com, they include

add copy, wrap, format & reset btns
add PWA screenshots & sharing to PWA
detect offline/online mode
faster preloading & prefetching
prefetch workers
preload monaco.min.js for faster perf
and more....

You can read more about bundlejs.com on the Github repo,

okikio / bundlejs

An online tool to quickly bundle & minify your projects, while viewing the compressed gzip/brotli bundle size, all running locally on your browser.

bundlejs

✨ WOOOOOOH!! ✨ The bundlejs api is now out at deno.bundlejs.com and/or edge.bundlejs.com, bundle your code and get a badge.

Check out the announcement tweet

I see a badge, you see a badge, we all see badges!!!

To create a badge just replace the domain bundlejs.com domain with deno.bundlejs.com and add /?badge, yeah, that simple

A small online tool for checking the minified gzip/brotli size of npm packages.

I used monaco-editor for the code-editor, esbuild as bundler and treeshaker respectively, denoflate as a wasm port of gzip, deno_brotli as a wasm port of brotli, deno_lz4 as a wasm port of lz4, bytes to convert the compressed size to human readable values, esbuild-visualizer to visualize and analyze your esbuild bundle to see which modules are taking up space and, umami for private, publicly available analytics and general usage stats all without cookies.

This project was greatly influenced by…

View on GitHub

Github Codespaces vs. Gitpod: Choosing the Best Online Code Editor

Okiki Ojo — Thu, 02 Sep 2021 13:44:01 +0000

Gitpod and Github Codespaces are both Visual Studio Code based online code editors, with attached Linux dev environment servers, for running terminal tasks; in simple terms, both are cloud-based code editors, and are free* to use.

Note: Github Codespaces is only free for personal use during its beta period, which might change in the future, for Github Teams and Organizations there is a pay-as-you-go pricing setup. To get access to personal Github Codespaces you will need to sign up for the beta.

This article details my personal experiences with Gitpod and Github Codespaces, these are my opinions and not definitive facts, your experiences may differ from mine.

Why online IDEs?

I have more experience with Gitpod, as it's been around for quite a bit longer than Github Codespaces, however, my experience with online code editors and IDEs is longer than that.

My first experience with an online code editor was Cloud9 in 2016 (this was before Cloud9 was bought by Amazon and became AWS Cloud9). At the time Cloud9 was a free service and was readily available for personal use, I loved the convenience of the service, so much so, that I fully switched from programming locally to programming online for a short period. All good things come to an end, by December 2019, Cloud9 announced that they were shutting down their standalone service, and instead, Cloud9 would be offered as part of AWS, so, just before I lost access to Cloud9, I started searching for alternatives, ranging from Eclipse Che, Red Hat CodeReady Workspaces, Codeanywhere to StackBlitz, out of all the alternatives the most competent of them was Gitpod.

The online vscode revolution

The main reason I searched for alternatives was that at that point in time I was attempting to use a Chromebook for all my work. When I found Gitpod I liked the general user experience it was similar to vscode but had some extra additions that made more sense in an online environment, such as the ability to open small previews of websites while developing, etc... Plus, online editors were the only way to code on a Chromebook (this has now changed. Chrome OS now supports Linux as a subsystem), so, 🤷‍♂️.

Gitpod vs. Codespaces

Gitpod themselves already made an article about their benefits over Github Codespaces, you can find it here gitpod.io/gitpod-vs-github-codespaces. I will give a brief overview of the differences between the two, note where they overstate their differences and benefits, explain how to make the most of the each service, and then give my personal take on both services.

The first point Gitpod makes is that it's "Ready in a flash"

Gitpod removes long init and build times by continuously pre-building workspaces for your project. Thereby it allows you to start coding or debugging immediately, from any context, at any time.

This is technically correct, at least to a certain point. Gitpod's actual building process takes slightly longer than that of Github Codespaces or at the very least it feels that way, I haven't, nor do I plan to give any exact empirical performance data, as both services are constantly changing things, in fact, the week before I wrote this article, Github introduced github.dev.

FYI (For your information): github.dev is an online vscode based web editor, the difference between this and Github Codespaces, is that Codespaces comes with a terminal, and this doesn't

In the defense of Gitpod, it can prebuild a workspace unlike Github Codespaces, so you can start coding immediately, without having to wait for the long build process to finish.

Another point that Gitpod makes is that it has "3x more power",

By leveraging cloud technologies like containers and Kubernetes, Gitpod achieves best-in-class resource efficiency with scalable workspaces running on shared high-powered cloud servers.

This is probably the iffiest points they make, since I can't verify their server configs, nor can I verify that the plans they used for testing, end up being cheaper in actual use, especially, since Github has only released the pricing scheme for Github Teams and Enterprise, and not personal use.

As of August 30, 2021, Gitpod has 4 plans*, they are,

Plan	Price (Per User/Month)	Features
Open Source	Free	50 hours/month + Private & Public Repos
Personal	$9	100 hours/month + 4 Parallel Workspaces + 30min Timeout
Professional	$25	All in Personal + 8 Parallel Workspaces + Unlimited Hours + Teams
Unleashed	$39	All in Professional + 16 Parallel Workspaces + 1hr Timeout + 3hr Timeout boost

For Github Codespaces, the pricing* is,

Product	SKU	Unit of measure	Price
Codespaces Compute	2 core	1 hour	$0.18
	4 core	1 hour	$0.36
	8 core	1 hour	$0.72
	16 core	1 hour	$1.44
	32 core	1 hour	$2.88
Codespaces Storage	Storage	1 GB-month	$0.07

*Both services have more details included in their pricing scheme, I recommend going through those for detailed and up-to-date information.

Note: You have to pay for your Codespaces storage for the time while said workspace exists, this includes while you are not actively using the workspace. Gitpod to my knowledge doesn't require paying for storage.

Sources: Gitpod, GitHub Codespaces.

In the final point Gitpod makes, they list some of the benefits they offer in a table-like format, I will be blatantly honest, they are leaving out quite a lot of details, so, I will answer in kind but in a more detailed manner.

	Gitpod	Github Codespaces	Details
PRICING (HOSTED)	Free for Open-Source	$$$	Again, this is iffy, as it makes conclusions about Gitpod's prices being cheaper, that isn't quite accurate, and is rather misleading
LICENSE	Open Source	Proprietary	This is where Gitpod gets a win, their code is actually open source, in-fact their extensions store uses the open-source OpenVSX extension store, however, the OpenVSX store ends up being both a benefit and a detriment.
GITHUB INTEGRATION	Yes	Yes	Gitpod has good support for Github, but Codespaces has better integration. Gitpod requires an Open in Gitpod link or the Gitpod extension, but Github Codespaces just works right out of the gate, click on any green code dropdown on Github and it will just open Codespaces.
GITLAB INTEGRATION	Yes	No	Accurate
BITBUCKET INTEGRATION	Yes	No	Accurate
SELF-HOST ON GCP	Yes	No	Accurate
SELF-HOST ON AWS	Yes	No	Accurate
SELF-HOST ON KUBERNETES	Yes	No	Accurate
PREBUILDS	Yes	No	Accurate
SNAPSHOTS	Yes	No	Assume it's Accurate. In the Github Codespaces beta, you can't share snapshots of workspaces, essentially, each user is forced to build each repo from scratch, for their use case. At least to my knowledge, I am not sure, whether this limitation applies to Github Teams and/or Organizations.
VS CODE EXTENSIONS	Yes*	Yes	Gitpod uses the OpenVSX store, the problem is that the OpenVSX store ends up being both a benefit and detriment to Gitpod. VS Code is open-source, but its store is closed source, so Eclipse created the Open VSX store, an open-source alternative, the problem is that a bunch of extensions are missing from the OpenVSX store, ranging from Github Copilot to Live Share and even some open-source extensions that you would expect to be available. In this case, I think Github Codespaces has the better extension store, as it directly uses the same extension store that the local installation of VS Code would use.
IPAD SUPPORT	Yes	Yes	Accurate
VIRTUAL DESKTOP (VNC)	Yes	Yes	Accurate
MULTI-IDE SUPPORT	Yes*	No	I guess this is accurate. Gitpod allows you to change the base of their service from VS Code to Theia (a fully open-source variant of VS Code), I personally find Theia subpar compared to VS Code, so, it's not really a feature that will either add or remove to your experience while using Gitpod or Github Codespaces.

Workspace Setup

Both Gitpod and Github Codespaces have config files based on Docker that configures your whole env. On Gitpod their config system uses a .gitpod.yml file which stores your workspace config info and a .gitpod.Dockerfile file which sets up a docker image that you can use to run your workspace. By default, Gitpod uses a standard docker image as the foundation for workspaces, the standard image has most of the default tools and programs devs require, plus you can also build on top of it to add small additions to it.

The .gitpod.yml files store basic configuration information, ranging from open ports to post-install scripts. Your basic .gitpod.yml files look like this:

# Commands to start on workspace startup
tasks:
  - init: yarn install
    command: yarn build
# Ports to expose on workspace startup
ports:
  - port: 8000
    onOpen: open-preview

For most of the projects I use Gitpod for, I set up a .gitpod.yml file like this

# .gitpod.yml
image:
  file: .gitpod.Dockerfile

# List the ports you want to expose and what to do when they are served. See https://www.gitpod.io/docs/43_config_ports/
ports:
  - port: 3000
    onOpen: open-preview
  - port: 3001
    onOpen: ignore

github:
  prebuilds:
    # enable for the master/default branch (defaults to true)
    master: true
    # enable for all branches in this repo (defaults to false)
    branches: true
    # enable for pull requests coming from this repo (defaults to true)
    pullRequests: true
    # enable for pull requests coming from forks (defaults to false)
    pullRequestsFromForks: true
    # add a "Review in Gitpod" button as a comment to pull requests (defaults to true)
    addComment: true
    # add a "Review in Gitpod" button to pull requests (defaults to false)
    addBadge: false
    # add a label once the prebuild is ready to pull requests (defaults to false)
    addLabel: prebuilt-in-gitpod

# List the start up tasks. You can start them in parallel in multiple terminals. See https://www.gitpod.io/docs/44_config_start_tasks/
tasks:
  - init: >
      npm install -g pnpm &&
      pnpm install -g ultra-runner &&
      pnpm install
    command: >
      npm install -g pnpm &&
      pnpm install -g ultra-runner &&
      pnpm build

The Gitpod prebuilds section sets up a prebuild for each branch, and pull request, and leaves a comment with a link to the prebuild, check out the docs for Gitpod prebuilds to learn more.

However, where things get interesting is in the tasks section. The init task is run once on workspace startup, and the command task is run on workspace startup, and then on every workspace restart.

The real problem is that the init task even though it runs on startup, doesn't store any globally installed packages, and from what I can tell this comes from the fact that every terminal environment is based on the Gitpod docker image, as in it basically forces the newly created terminal to use the Gitpod docker image, I recommend reading through Gitpod's docs on the matter.

The .gitpod.Dockerfile, is the file that directly gives you admin access, and enables you to install/do anything you want to your workspace. From my experience, you most likely won't need to change anything in here, except maybe for VNC, and even then, the docs are very clear.

# .gitpod.Dockerfile
FROM gitpod/workspace-full:latest

# Install custom tools, runtime, etc. using apt-get
# For example, the command below would install "bastet" - a command-line tetris clone:
#
# RUN sudo apt-get -q update && 
#     sudo apt-get install -yq bastet && 
#     sudo rm -rf /var/lib/apt/lists/*
#
# More information: https://www.gitpod.io/docs/config-docker/

On the other hand, setting up a workspace for Github Codespaces is hands-on. Picking a default container is easy enough*, you just follow the docs on VS Code, the real problem is that the setup for Github Codespaces is very overwhelming.

For Codespaces you need to create a .devcontainer.json file and store it in the .devcontainer/ folder. The .devcontainer.json file is a json file that contains the information needed to set up your workspace. The .devcontainer.json file looks like this:

// For format details, see https://aka.ms/devcontainer.json. For config options, see the README at:
// https://github.com/microsoft/vscode-dev-containers/tree/v0.162.0/containers/typescript-node
{
  "name": "Node.js & TypeScript",
  "build": {
    "dockerfile": "Dockerfile",
    // Update 'VARIANT' to pick a Node version: 10, 12, 14
    "args": {
      "VARIANT": "16"
    }
  },

  // Set *default* container specific settings.json values on container create.
  "settings": {
    "npm.packageManager": "pnpm"
  },

  // Add the IDs of extensions you want to be installed when the container is created.
  "extensions": [
    "bierner.jsdoc-markdown-highlighting",
    "yzhang.markdown-all-in-one",
    "shd101wyy.markdown-preview-enhanced",
    "visualstudioexptteam.vscodeintellicode"
  ],

  // Use 'forwardPorts' to make a list of ports inside the container available locally.
  "forwardPorts": [3000],

  // Use 'postCreateCommand' to run commands after the container is created.
  "postCreateCommand": "pnpm install",

  // Comment out connect as root instead. More info: https://aka.ms/vscode-remote/containers/non-root.
  "remoteUser": "node"
}

You also need to create a Dockerfile stored inside the .devcontainer/ folder. The Dockerfile contains docker info, so any configs, you require for your workspace can be set here, like this:

# See here for image contents: https://github.com/microsoft/vscode-dev-containers/tree/v0.187.0/containers/typescript-node/.devcontainer/base.Dockerfile

# [Choice] Node.js version: 16, 14, 12
ARG VARIANT="16-buster"
FROM mcr.microsoft.com/vscode/devcontainers/typescript-node:0-${VARIANT}

# [Optional] Uncomment this section to install additional OS packages.
# RUN apt-get update && export DEBIAN_FRONTEND=noninteractive \
#     && apt-get -y install --no-install-recommends <your-package-list-here>

# [Optional] Uncomment if you want to install an additional version of node using nvm
# ARG EXTRA_NODE_VERSION=10
# RUN su node -c "source /usr/local/share/nvm/nvm.sh && nvm install ${EXTRA_NODE_VERSION}"

# [Optional] Uncomment if you want to install more global node packages
# RUN su node -c "npm install -g <your-package-list -here>"

RUN su node -c "npm install -g pnpm"

This example is based on one of my Github projects okikio/native, it's a good starting point for setting up a workspace for your own project.

Note: The major thing that can throw you off with the Github Codespaces config is that you can't install local packages (I'm talking about node_modules) inside the docker config. Of course, this could be my lack of experience with Docker, but thus far I've been unable to get it to work properly.

FYI: The Gitpod team is planning to add support for the Github Codespaces devcontainer.json format, so, in the future, you might be able to easily switch between both Github Codespaces and Gitpod without breaking a sweat.

Collaboration

I personally haven't collaborated with anyone on Gitpod or Github Codespaces, but each service does offer a way to collaborate with others. For one, Gitpod allows you to share workspaces with others, and for the other, Github Codespaces allows you to use Live Share to collaborate on the same project.

I feel Live Share is a better collaboration tool, sure with Gitpod you can share workspaces with others, but with Codespaces you can both be working on the same project, without skipping a beat, and technically it would be very similar to sharing workspaces with other devs, so...I'll leave the final judgment of this to you.

Documentation

Github Codespaces has highly detailed documentation, but it's very content dense and a tad bit overwhelming. Gitpod's documentation on the other hand is simpler and more focused on the basics, it's a great way to get started with an online editor. Github Codespaces basically assumes you're already very experienced, while Gitpod assumes you're new to the world of online code editors and slowly builds on top.

VNC

Gitpod and Github Codespaces both have VNC support. From my experiences, both are about equal in terms of how VNC works, however, Gitpod is easier to set up with VNC.

Virtual Network Computing (VNC) is a graphical desktop-sharing system that uses the Remote Frame Buffer protocol (RFB) to remotely control another computer. It transmits the keyboard and mouse input from one computer to another, relaying the graphical-screen updates, over a network. Read more on Wikipedia

A little while back I tried experimenting to see if I could set up Webkit (Safari's browser engine) on my Windows laptop...I failed, I couldn't figure out how to build the Webkit source code on Windows (it was painfully difficult), so, I tried the next best thing, the "cloud", it too failed, but interestingly enough, for a vastly different reason.

For this experiment, I used Github Codespaces (for a previous experiment I had already tried using Gitpod with VNC, so, I thought I would try Github Codespaces this time). I was able to get VNC functional but couldn't set up Webkit, since, Docker has problems with some of the libraries that Webkit uses. I tried for a good ~16 hours before I gave up. I eventually found another alternative, Playwright.

Playwright is an end-to-end framework for testing web apps on multiple browsers, it's a great tool for testing web apps.

While trying out Playwright, I found it would only work on Windows (this was because of Webkit & Docker's library issue).

Let's get back to the original topic, VNC. In my experiments, I found setting up VNC on Github Codespaces difficult and the build process for said workspace long, I actually timed it, the build process for Github Codespaces with VNC was ~6 minutes, while, on Gitpod it was much faster (I can't remember exactly how long it took, but what I do remember is that it was less than 5 minutes), also, Gitpod's documentation is much easier to digest and just get started with.

For VNC on Gitpod check out gitpod.io/blog/native-ui-with-vnc.

For VNC on Github Codespaces check out github.com/microsoft/vscode-dev-containers/blob/main/script-library/docs/desktop-lite.md.

Annoyances

In Gitpod workspaces every terminal is built from the initial docker image, in theory, this sounds awesome, however, from my experience, it ends up being a huge pain to work around. For example, I have found that if you, use nvm (node version manager) to install a new version of node, let's say v16 to replace the Gitpod standard images node, v14, every new terminal you create will use the version of node set up in the standard image, this seems like a very minor issue, but it can cause a bunch of issues and just make you very annoyed over time, plus it just slows down your development velocity.

The Internet Problem

By using Gitpod and Github Codespaces, you become reliant on the internet, and if you don't have access to the internet, you can't use either service. For most devs, this isn't really a problem, since, in most cases, they need access to the internet to commit changes to Github, Bitbucket, etc...

For cases where you don't have access to the internet, let's say your ISP messed up somewhere and you lose access for a couple days (I am speaking from personal experience here), then you become unable to do any programming at all.

For those who are worried about internet connections the best thing you can do is, to make sure you always have a local copy with all the tools and dependencies already installed, so, you can at least make some progress when you lose access.

For small instances where you lose connection for maybe a minute or two, Github Codespaces and Gitpod keep local copies of all open files, and merge them into the online copy when the connection is re-established, so, no worries there.

Warning: One thing you should pay attention to is, if you lose internet access for a long time while using Gitpod, you may lose your workspace, and have to start over. This doesn't really apply to Github Codespaces, since you must actively delete a workspace, Codespaces will shut down a workspace, but it won't delete it for you.

Miscellaneous

A minor difference between Gitpod and Github Codespaces is that Github Codespaces supports using your locally installed version of VS Code to continue development using the VS Code you know and love, as well as forwarding remote ports to localhost ports and much more, all together Github Codespaces allows devs to develop in an environment very similar to local developments except with less resource use (as most of the processing is happening on the remote server), and slightly greater dependence on the internet, read through Github's docs to learn more.

Gitpod supports something similar, if you install the Gitpod app as a PWA (from what I know, only Edge allows you to forcefully install websites as apps), you can then forward the remote ports on the server to your computer's localhost ports, read more about this on Gitpod's docs.

FYI: Gitpod is working on support for local VS Code, so, by the time you are reading this article it might already be live.

I don't know how important this is to devs, but Github Codespaces automatically syncs settings, between VS Code and itself. To use this feature with Gitpod, you need to do some setup with your VS Code installation, read through the issue opened by Gitpod to learn more.

When to use Github Codespaces?

Github Codespaces is an easy to use and reliable VS Code service, its integration with Github is quite convenient and is hard to properly quantify, its extension support is top tier, its a coding experience that is hard to pass on, especially for devs who already use Github's other services. Github Codespaces is great for devs who need high-resource workspaces and are ok without self-hosting on other platforms.

Github Codespaces is good, but it's not the perfect solution for everyone. Github's billing model is a bit strenuous, as workspace storage is not free, so, if you want to use Github Codespaces professionally, you might end up paying quite a bit unintentionally, plus, depending on how many hours you use each Github Codespace, your monthly bill can be a rather painful pill to swallow.

When to use Gitpod?

Gitpod is an easy-to-use and very reliable VS Code service, and its open-source design allows you to get involved, maybe even fix issues as they arise. Gitpod is great for open-source projects, for those that want a reliable and consistent monthly pricing scheme, for devs looking for non-proprietary VS Code workspaces, or devs that want to use Bitbucket, Gitlab, etc.. and/or to use a self-hosted option on AWS, GCP, etc... Really Gitpod is great for the same reasons as Github Codespaces, it just has a little less Github integration which makes Github Codespaces a nicer experience to use with Github.

Conclusion

Both services are amazing, as they bring a consistent and reliable VS Code experience to devs via the web. However, they are not the perfect solution for everyone, as they each have their ups and downs.

I have stated my personal experience with both services, and I would recommend using the one that you feel is best for you. Personally, I switch between both services rather often, however, I prefer Github Codespaces. I find it to be the best option for me as it syncs my settings, supports local VS Code, and has great integration with Github and VS Code extensions (I am even able to use Github Copilot in Github Codespaces).

Note: I actually used Github Codespaces together with Github Copilot to write this article. Trust me when I say it's an excellent writing companion, it's almost like the Gmail autocomplete, but better, since it also recognizes code syntax, and can apply them rather effectively.

For a more neutral and objective comparison between both services, I suggest reading through Nader Dabit's article on FreeCodeCamp comparing the two.

The idea for this article came from a tweet by Nik Molnar @nikmd23 and Stephan Meijer @meijer_s.

Photo by Okiki Ojo, you can find the image on Dropbox.

Originally published on blog.okikio.dev

Also, published on Hackernoon

GZIP on the Browser

Okiki Ojo — Tue, 27 Jul 2021 15:50:12 +0000

Out of curiosity I created a small demo detailing how you can implement GZIP in the browser, I used fflate for the GZIP compression, and pretty-bytes to convert bytes into human readable format, the demo is really small but as an example it should be more than good enough. I based it on bundlejs.com. Interestingly, I have yet to find a website that lets you see the GZIP size of some random text, all the ones I have found so far expect you to upload a file, the little demo takes a string as an input compresses it, and gives you the final size.

I suggest checking out bundlejs.com it's a specialized for bundling, minifying and compressing js, all locally, right on your browser.

Check out the product hunt page for bundlejs.com.

What are your opinions of the Web Animation API (WAAPI)?

Okiki Ojo — Sat, 10 Jul 2021 07:48:37 +0000

I recently learned Matt Perry the creator of Framer Motion, Popmotion, and Pose is creating another animation library based on the Web Animation API.

// Detect dark theme var iframe = document.getElementById('tweet-1412121262449627140-844'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1412121262449627140&theme=dark" }

Similarly, last year I created @okikio/animate an animation library based on the Web Animation API.

So, I am wondering is there any actual interest in a an animation library that uses the Web Animation API?

Forem: Okiki Ojo

Hot take: Apple v US gov't, the US gov't is right

From Docker to Podman - VS Code DevContainers

Been a while... 👀

A Quick Refresher on DevContainers 🏝

The Podman Appeal 🎸

The Challenge: VS Code Loves Docker

The Solution: Trick VS Code with a Shell Script

macOS

Step 1: Install Podman

Step 2: Initialize and Start Podman Machine

Step 3: Create a Shell Script

Step 4: Make the Script Executable

Step 5: Restart VS Code

Linux

Step 1: Install Podman

Steps 2-5: Follow the same steps as for macOS

Windows

Step 1: Install Podman for Windows

Step 2: Create a Batch File

Option 1: Use an Existing Directory in PATH

Option 2: Create a New Directory and Add It to PATH

Verify the Setup

Step 3: Restart VS Code

Wrapping Up

ESM & CJS: The subtle shift in bundlejs' behaviour

The Issue at Hand 🧐

The Solution 🧩

Mastering the Art of ESM and CJS Package Handling

The Issue at Hand 🧐

The Solution 🧩

Vercel + Support Center = 🚀

How to upload files with Astro

Introduction

Getting started

Usage

Easy Way

Hard Way

Conclusion

bundlejs: An online esbuild based bundler & npm package size checker

Introduction

Quick feature run down

Bundling, Treeshaking, and Minification

Console

Input and Output Tabs

Configuration

CDN Hosts

Compression Algorithms

The Brotli Problem

Default to Gzip

LZ4, Gotta Go Fast

Compression Quality

Aliases and Externals

Esbuild Config Options

Editor Buttons + Extra Features...

Drag Handles...Interactive Fun

JSX Support

Sharing Bundle Sessions

Bundle Analysis

Analytics

Setting up Umami with Vercel and Supabase

Jakob Bouchard ・ Feb 2 '21

Discussions and Support

Security and Performance

Tips and Tricks

Contribute

Conclusion

@okikio/sharedworker, SharedWorkers on all browsers

okikio / sharedworker

A small spec. compliant polyfill for SharedWorkers, it acts as a drop in replacement for normal Workers.

@okikio/sharedworker

Installation

Usage

Usage

Limitation

Conclusion

Major updates for bundlejs.com v0.0.3

okikio / bundlejs

An online tool to quickly bundle & minify your projects, while viewing the compressed gzip/brotli bundle size, all running locally on your browser.

bundlejs

Option 1: Use an Existing Directory in `PATH`

Option 2: Create a New Directory and Add It to `PATH`