This loader optimizes the output of mini-css-extract-plugin and/or css-loader,
entirely removing the potentially large CSS classname mappings normally inlined into your bundle when using CSS Modules.
Run npm install constant-locals-loader, then make these changes in your Webpack config:
module.exports = {
module: {The following worked with Elastic Cloud, Elasticsearch & Kibana v7.6.0. It should be pretty close for other kinds of deployments. Before starting, make sure you have the right license level that allows SAML.
This gist summarizes the handleEvent(event) pattern features, something standard, something described by me many times, written in my tiny book, tweeted about, and yet it's something most Web developers ignore.
┌---------------------------------┐
var handler = { | any object that inherits or |
The first post has been published: https://www.swyx.io/writing/cloud-distros
The second post has been adapted for Temporal: https://www.swyx.io/why-temporal/
these are bullet points of a blogpost on a topic i know very little about but i feel like there is something there that is happening as we speak
registry=localhost:32000
repositories=$(curl ${registry}/v2/_catalog)
for repo in $(echo "${repositories}" | jq -r '.repositories[]'); do
echo $repo
tags=$(curl -sSL "http://${registry}/v2/${repo}/tags/list" | jq -r '.tags[]')
for tag in $tags; do
echo $tag
curl -v -sSL -X DELETE "http://${registry}/v2/${repo}/manifests/$(
curl -sSL -I \
| // Package handler (directory named 'api/') is recognized | |
| // by ZEIT Now v2 Lambda platform. | |
| package handler | |
| import ( | |
| "net/http" | |
| ) | |
| func init() { log.SetFlags(log.Lmicroseconds) } |
This is some sort of answer to recent posts regarding Web Components, where more than a few misconceptions were delivered as fact.
Let's start by defining what we are talking about.
As you can read in the dedicated GitHub page, Web Components is a group of features, where each feature works already by itself, and it doesn't need other features of the group to be already usable, or useful.
| <!DOCTYPE html> | |
| <html> | |
| <head> | |
| <title>Demo: Treat Safari 11 and Prior as nomodule</title> | |
| </head> | |
| <body> | |
| <script> | |
| if (/Safari\/5/.test(navigator.userAgent)) { | |
| var $fss = function () { | |
| for (var i of document.scripts) { |
We're getting Constructable Stylesheets. This seems like an intuitive value to obtain when importing CSS from JavaScript, since it's the DOM's representation of a Stylesheet:
import stylesheet from './style.css';
console.log(stylesheet); // CSSStyleSheetNo such system is in place to allow this to work (see [whatwg/loader]), however frontend build tooling has congregated around this approach as a mechanism for bringing CSS assets into the JavaScript module graph. There are many benefits to be obtained from moving CSS into this graph, however the most important is that imported CSS can be attributed to the consuming JS Module. This allows it to be bundled, optimized, and potentially dead-code-eliminated leveraging static analysis performed on the surrounding module graph.
With the addition of ES modules, there's now no fewer than 24 ways to load your JS code: (inline|not inline) x (defer|no defer) x (async|no async) x (type=text/javascript | type=module | nomodule) -- and each of them is subtly different.
This document is a comparison of various ways the <script> tags in HTML are processed depending on the attributes set.
If you ever wondered when to use inline <script async type="module"> and when <script nomodule defer src="...">, you're in the good place!
Note that this article is about <script>s inserted in the HTML; the behavior of <script>s inserted at runtime is slightly different - see Deep dive into the murky waters of script loading by Jake Archibald (2013)