Skip to content

Instantly share code, notes, and snippets.

@sindresorhus
sindresorhus / esm-package.md
Last active May 6, 2024 10:25
Pure ESM package

Pure ESM package

The package that linked you here is now pure ESM. It cannot be require()'d from CommonJS.

This means you have the following choices:

  1. Use ESM yourself. (preferred)
    Use import foo from 'foo' instead of const foo = require('foo') to import the package. You also need to put "type": "module" in your package.json and more. Follow the below guide.
  2. If the package is used in an async context, you could use await import(…) from CommonJS instead of require(…).
  3. Stay on the existing version of the package until you can move to ESM.
@pgchamberlin
pgchamberlin / MutationObserverLogger.js
Created December 5, 2012 17:47
Snippet that logs DOM mutations using the MutationObserver API
<script type="text/javascript">
// See MDN: https://developer.mozilla.org/en-US/docs/DOM/MutationObserver?redirectlocale=en-US&redirectslug=DOM%2FDOM_Mutation_Observers
(function(){
// select the target node
var target = document.querySelector('body');
var MutationObserver = window.MutationObserver || window.WebKitMutationObserver || window.MozMutationObserver;
var i=0;
// create an observer instance
var observer = new MutationObserver(function(mutations) {
@benfoxall
benfoxall / MutationObserverLogger.js
Created December 5, 2012 18:10 — forked from pgchamberlin/MutationObserverLogger.js
Snippet that logs DOM mutations using the MutationObserver API
<script type="text/javascript">
// See MDN: https://developer.mozilla.org/en-US/docs/DOM/MutationObserver?redirectlocale=en-US&redirectslug=DOM%2FDOM_Mutation_Observers
(function(){
// select the target node
var target = document.querySelector('body');
var MutationObserver = window.MutationObserver || window.WebKitMutationObserver || window.MozMutationObserver;
var i={};
// create an observer instance
var observer = new MutationObserver(function(mutations) {
<script type="text/javascript">
// See MDN: https://developer.mozilla.org/en-US/docs/DOM/MutationObserver?redirectlocale=en-US&redirectslug=DOM%2FDOM_Mutation_Observers
(function(){
// select the target node
var target = document.querySelector('body');
var MutationObserver = window.MutationObserver || window.WebKitMutationObserver || window.MozMutationObserver;
var i={};
// create an observer instance
var observer = new MutationObserver(function(mutations) {
@jaymody
jaymody / docker_save_progress_bar.sh
Created June 2, 2020 23:43
docker save with a progress bar
# If you're impatient like me, a progress bar can be a comforting way to impulsively check the progress
# of your docker save command
#
# You'll need tqdm installed (https://github.com/tqdm/tqdm) for this to work.
docker save IMAGE_NAME | tqdm --bytes --total $(docker image inspect IMAGE_NAME --format='{{.Size}}') > OUTPUT_TAR_NAME
@Rich-Harris
Rich-Harris / footgun.md
Last active May 6, 2024 10:24
Top-level `await` is a footgun

Edit — February 2019

This gist had a far larger impact than I imagined it would, and apparently people are still finding it, so a quick update:

  • TC39 is currently moving forward with a slightly different version of TLA, referred to as 'variant B', in which a module with TLA doesn't block sibling execution. This vastly reduces the danger of parallelizable work happening in serial and thereby delaying startup, which was the concern that motivated me to write this gist
  • In the wild, we're seeing (async main(){...}()) as a substitute for TLA. This completely eliminates the blocking problem (yay!) but it's less powerful, and harder to statically analyse (boo). In other words the lack of TLA is causing real problems
  • Therefore, a version of TLA that solves the original issue is a valuable addition to the language, and I'm in full support of the current proposal, which you can read here.

I'll leave the rest of this document unedited, for archaeological

@Rich-Harris
Rich-Harris / imperative-v-declarative-imports.md
Last active May 6, 2024 10:23
Why imperative imports are slower than declarative imports

Why imperative imports are slower than declarative imports

A lot of people misunderstood Top-level await is a footgun, including me. I thought the primary danger was that people would be able to put things like AJAX requests in their top-level await expressions, and that this was terrible because await strongly encourages sequential operations even though a lot of the asynchronous activity we're talking about should actually happen concurrently.

But that's not the worst of it. Imperative module loading is intrinsically bad for app startup performance, in ways that are quite subtle.

Consider an app like this:

// main.js
const axios = require('axios').default;
const TC_HOST = 'cardano-testnet-staging.tangocrypto.com';
const TC_APP_ID = 'xxxxxxxxx';
const TC_API_KEY = 'xxxxxxxxx';
const NMKR_auth = 'xxxxxxxxxx';
const NMKR_host = 'studio-api.testnet.nmkr.io';
const NMKR_collection_id = '5d0c151f-03d7-4320-8252-096a3642c080'
@uxgnod
uxgnod / calc_pvq.sql
Last active May 6, 2024 10:23
calc pvq total
SELECT *
FROM (
SELECT
o.distributor_id,
ui.firstname || ' ' ||ui.lastname distributor_name,
ui.phone,
ui.email,
to_char(o.state_date, 'YYYY-MM') qualified_date,
sum(o.pvq) pvq_total
FROM user_infos ui
@tyhopp
tyhopp / render-to-pipeable-stream-error-handling.js
Last active May 6, 2024 10:23
renderToPipeableStream error handling
const React = require(`react`);
const { renderToPipeableStream } = require(`react-dom/server`);
const { Writable } = require(`stream`);
function MyComponent() {
throw new Error(`My error`);
}
class MyWritableStream extends Writable {
constructor() {