"Who would dare assert that we know all there is to be known?" ~ Galileo Galilei
At the time of this writing there are 3 separate libraries that offer assertions for the Bash Automated Testing System (otherwise known as BATS).
These are:
<!-- | |
Complete feature detection for ES modules. Covers: | |
1. Static import: import * from './foo.js'; | |
2. Dynamic import(): import('./foo.js').then(module => {...}); | |
Demo: http://jsbin.com/tilisaledu/1/edit?html,output | |
Thanks to @_gsathya, @kevincennis, @rauschma, @malyw for the help. | |
--> |
build:install-vendor: | |
stage: build | |
image: <any-image-with-composer> | |
before_script: | |
- composer config -g cache-dir "$(pwd)/.composer-cache" | |
script: | |
- composer install --ignore-platform-reqs --no-dev --optimize-autoloader --no-ansi --no-interaction --no-progress | |
cache: | |
paths: | |
- .composer-cache/ |
workspace: | |
base: /build | |
pipeline: | |
dbnode1: | |
detach: true | |
image: mysql/mysql-cluster:7.5 | |
commands: | |
- sleep 5 |
"Who would dare assert that we know all there is to be known?" ~ Galileo Galilei
At the time of this writing there are 3 separate libraries that offer assertions for the Bash Automated Testing System (otherwise known as BATS).
These are:
FROM php:7.2-fpm | |
# Replace shell with bash so we can source files | |
RUN rm /bin/sh && ln -s /bin/bash /bin/sh | |
# make sure apt is up to date | |
RUN apt-get update --fix-missing | |
RUN apt-get install -y curl | |
RUN apt-get install -y build-essential libssl-dev zlib1g-dev libpng-dev libjpeg-dev libfreetype6-dev |
addEventListener('fetch', event => { | |
event.respondWith(handleRequest(event)) | |
}) | |
/** | |
* Entry point of the worker | |
*/ | |
async function handleRequest(event) { | |
try { | |
// Get the JWT |
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)
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); // CSSStyleSheet
No 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.
<!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) { |
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.