davidbgk
/
larlet-fr-david-cache
Observar 1
Favorito 0
Fork 0
Código Versões 0 Atividade
Ver código fonte

More links

master
David Larlet 3 anos atrás
pai
6227b76e2e
commit
afb9413255
3 arquivos alterados com 226 adições e 0 exclusões
Visão dividida Mostrar estatísticas do Diff
  1. 219
    0
      cache/2021/4b81d4d9d89fb1d417aa292463529271/index.html
  2. 5
    0
      cache/2021/4b81d4d9d89fb1d417aa292463529271/index.md
  3. 2
    0
      cache/2021/index.html

+ 219
- 0
cache/2021/4b81d4d9d89fb1d417aa292463529271/index.html Ver arquivo

@@ -0,0 +1,219 @@
<!doctype html><!-- This is a valid HTML5 document. -->
<!-- Screen readers, SEO, extensions and so on. -->
<html lang="fr">
<!-- Has to be within the first 1024 bytes, hence before the <title>
See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->
<meta charset="utf-8">
<!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->
<!-- The viewport meta is quite crowded and we are responsible for that.
See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->
<meta name="viewport" content="width=device-width,initial-scale=1">
<!-- Required to make a valid HTML5 document. -->
<title>Vendor by default (archive) — David Larlet</title>
<meta name="description" content="Publication mise en cache pour en conserver une trace.">
<!-- That good ol' feed, subscribe :). -->
<link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/">
<!-- Generated from https://realfavicongenerator.net/ such a mess. -->
<link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png">
<link rel="manifest" href="/static/david/icons2/site.webmanifest">
<link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c">
<link rel="shortcut icon" href="/static/david/icons2/favicon.ico">
<meta name="msapplication-TileColor" content="#f0f0ea">
<meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml">
<meta name="theme-color" content="#f0f0ea">
<!-- Documented, feel free to shoot an email. -->
<link rel="stylesheet" href="/static/david/css/style_2021-01-20.css">
<!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. -->
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<script>
function toggleTheme(themeName) {
document.documentElement.classList.toggle(
'forced-dark',
themeName === 'dark'
)
document.documentElement.classList.toggle(
'forced-light',
themeName === 'light'
)
}
const selectedTheme = localStorage.getItem('theme')
if (selectedTheme !== 'undefined') {
toggleTheme(selectedTheme)
}
</script>

<meta name="robots" content="noindex, nofollow">
<meta content="origin-when-cross-origin" name="referrer">
<!-- Canonical URL for SEO purposes -->
<link rel="canonical" href="https://macwright.com/2021/03/11/vendor-by-default.html">

<body class="remarkdown h1-underline h2-underline h3-underline em-underscore hr-center ul-star pre-tick">

<article>
<header>
<h1>Vendor by default</h1>
</header>
<nav>
<p class="center">
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-home"></use>
</svg> Accueil</a> •
<a href="https://macwright.com/2021/03/11/vendor-by-default.html" title="Lien vers le contenu original">Source originale</a>
</p>
</nav>
<hr>
<p>This isn’t a recommendation. It’s more of a habit that I’ve acquired recently. If this makes its way to Hacker News and people think <em>how could he</em>, my only response will be 🤷, why not.</p>

<p>I’ve been building a thing, in JavaScript, an application sort of like things I’ve built in the past. With the same basic goal of making something useful. How I get to that goal is flexible. But it ends up being a lot of <a href="http://boringtechnology.club">using boring technology</a>, trying not to overthink the easy parts, trying to properly-think the hard parts, and so on. So there’s not that much to write home about that would surprise your usual React/Next.js/JavaScript engineer person.</p>

<p>But one thing that I do think is sort of unusual is: I’m vendoring <em>a lot of stuff</em>.</p>

<p><em>Vendoring</em>, in the programming sense, means “copying the source code of another project into your project.” It’s in contrast to the practice of using dependencies, which would be adding another project’s name to your <code class="language-plaintext highlighter-rouge">package.json</code> file and having npm or yarn download and link it up for you.</p>

<p>Back in 2016, I wrote <a href="https://macwright.com/2016/08/23/optimistic-pessimistic-versioning.html">an article about optimistic and pessimistic versioning, which mentioned vendoring</a> as the ‘most pessimistic’ approach, and that’s roughly true. Vendoring means that you aren’t going to get automatic bugfixes, or new bugs, from dependencies. It means that you don’t have to trust dependency authors at all.</p>

<p>The downsides of vendoring - no automatic updates, a bigger source tree, more code to maintain, it seems weird and unconventional - are probably pretty clear to JavaScripters, and most members of most language families. Languages like C did vendoring by default, in that people would copy header-only libraries into their projects. Go, for a while, was a little like that - you’d copy files in, whether automatically or manually. But nowadays Go modules (to my untrained eye) look a lot like the norms of other languages.</p>

<p>So what are the reasons for doing this? Here’s what’s on my mind.</p>

<h3 id="i-read-dependencies-anyway">I read dependencies anyway</h3>

<p>I read a lot of other people’s code. I highly recommend it. One of my golden rules is that you shouldn’t <a href="https://en.wikipedia.org/wiki/Black_box">blackbox</a> things you don’t need to. I like to “use dependencies for efficiency, not ignorance.”</p>

<p>When I’m vendoring code - copying it into the project and making it pass my basic eslint &amp; testing standards, I’ll do light rewrites and refactors of new code, allowing me to get a deeper understanding of how they work and where their limits lie.</p>

<p>Obviously, other people’s code is their code. I didn’t do 100% of the thinking that led to it - I’m probably doing 5% of it. But absorbing that bit into my mind, instead of seeing only the external API surface, pays dividends.</p>

<p>And sometimes, sure - I’ll read through a dependency, start refactoring, and realize that it’s going to be simpler to write it myself, or I should find another option. It doesn’t matter if something is a dependency or my code: when you ship a product, it’s all your responsibility.</p>

<h3 id="you-dont-really-use-most-of-your-dependencies">You don’t really use most of your dependencies</h3>

<p>Vendoring makes it very obvious that many dependencies have lots of surface area - API calls and methods - that you don’t use. This hooks into the debate about tiny modules (less surface area! less waste! way harder to maintain!), or big ones, but for this article, the point is that you can pare down dependencies into their ideal form in your application.</p>

<p><a href="https://webpack.js.org/guides/tree-shaking/">Dead code elimination</a> helps! But it can only do so much, and the dead code <em>still exists in your project.</em> Even the most advanced DCE isn’t going to pare down methods of a class that you’re using. Only some DCE systems can handle CommonJS, and most work on the level of individual variables, not <em>parts</em> of those variables.</p>

<p>To go a step further, you can trim the test suite down to the API surface you use, run coverage, and comment out or remove the parts that are dead.</p>

<h3 id="old-projects-stabilize">Old projects stabilize</h3>

<p>Old projects might not be stable. They might have bugs - they usually do. In every issue tracker, there’s at least one multi-year bug that is so wicked that it might never go away.</p>

<p>But old projects have <em>stabilized</em>. They don’t change that often, and when they do the changes are minor. So the value that you got out of that fast release cycle two years ago doesn’t apply. And worse - you have a lot of old patterns that the project probably can’t remove! Do you want IE10 workarounds in your project? If you’re using a lot of third-party dependencies, you’re probably inheriting polyfills for stuff like <code class="language-plaintext highlighter-rouge">Array.includes</code>.</p>

<p>In my brief rewrites, I can pluck out old-fashioned polyfills for <code class="language-plaintext highlighter-rouge">isArray</code> or code that checks that <code class="language-plaintext highlighter-rouge">JSON.parse</code> really exists in this environment. In 2021, it does.</p>

<h3 id="its-sort-of-good-for-open-source">It’s sort of good for open source</h3>

<p>This is a mixed bag. My vendored copy might float far away from the original, and contributing back the changes in full isn’t going to be useful. A lot of the changes that I make are going to be somewhat cosmetic or things like adding TypeScript support for things that didn’t have it.</p>

<p>But on the other hand, porting a fix from my vendored copy to the original is going to be pretty quick, and having dependencies in the source tree itself is an ideal scenario for fixing bugs in vendored code quickly.</p>

<p>Dependencies that are GPL’ed (there aren’t many, but the license still lingers) will get released when the thing is released, because the law requires it - though those changes won’t be especially exciting. Things that are MIT/BSD/ISC licensed will mostly get upstream fixes, for the good of the community.</p>

<h3 id="not-everything">Not <em>everything</em></h3>

<p>I don’t vendor React or Webpack or other large, incredibly complex dependencies. They’re going to change quickly and there’s little I can really contribute to those projects. I’m happy to keep <code class="language-plaintext highlighter-rouge">lodash</code> as a dependency for a few extremely battle-tested utilities. But for small to medium-sized dependencies, vendoring makes a lot of sense.</p>
</article>


<hr>

<footer>
<p>
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-home"></use>
</svg> Accueil</a> •
<a href="/david/log/" title="Accès au flux RSS"><svg class="icon icon-rss2">
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-rss2"></use>
</svg> RSS</a> •
<a href="http://larlet.com" title="Go to my English profile" data-instant><svg class="icon icon-user-tie">
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-user-tie"></use>
</svg> Pro</a> •
<a href="mailto:david%40larlet.fr" title="Envoyer un courriel"><svg class="icon icon-mail">
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-mail"></use>
</svg> Email</a> •
<abbr class="nowrap" title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340"><svg class="icon icon-hammer2">
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-hammer2"></use>
</svg> Légal</abbr>
</p>
<template id="theme-selector">
<form>
<fieldset>
<legend><svg class="icon icon-brightness-contrast">
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-brightness-contrast"></use>
</svg> Thème</legend>
<label>
<input type="radio" value="auto" name="chosen-color-scheme" checked> Auto
</label>
<label>
<input type="radio" value="dark" name="chosen-color-scheme"> Foncé
</label>
<label>
<input type="radio" value="light" name="chosen-color-scheme"> Clair
</label>
</fieldset>
</form>
</template>
</footer>
<script>
function loadThemeForm(templateName) {
const themeSelectorTemplate = document.querySelector(templateName)
const form = themeSelectorTemplate.content.firstElementChild
themeSelectorTemplate.replaceWith(form)

form.addEventListener('change', (e) => {
const chosenColorScheme = e.target.value
localStorage.setItem('theme', chosenColorScheme)
toggleTheme(chosenColorScheme)
})

const selectedTheme = localStorage.getItem('theme')
if (selectedTheme && selectedTheme !== 'undefined') {
form.querySelector(`[value="${selectedTheme}"]`).checked = true
}
}

const prefersColorSchemeDark = '(prefers-color-scheme: dark)'
window.addEventListener('load', () => {
let hasDarkRules = false
for (const styleSheet of Array.from(document.styleSheets)) {
let mediaRules = []
for (const cssRule of styleSheet.cssRules) {
if (cssRule.type !== CSSRule.MEDIA_RULE) {
continue
}
// WARNING: Safari does not have/supports `conditionText`.
if (cssRule.conditionText) {
if (cssRule.conditionText !== prefersColorSchemeDark) {
continue
}
} else {
if (cssRule.cssText.startsWith(prefersColorSchemeDark)) {
continue
}
}
mediaRules = mediaRules.concat(Array.from(cssRule.cssRules))
}

// WARNING: do not try to insert a Rule to a styleSheet you are
// currently iterating on, otherwise the browser will be stuck
// in a infinite loop…
for (const mediaRule of mediaRules) {
styleSheet.insertRule(mediaRule.cssText)
hasDarkRules = true
}
}
if (hasDarkRules) {
loadThemeForm('#theme-selector')
}
})
</script>
</body>
</html>

+ 5
- 0
cache/2021/4b81d4d9d89fb1d417aa292463529271/index.md
Diferenças do arquivo suprimidas por serem muito extensas
Ver arquivo


+ 2
- 0
cache/2021/index.html Ver arquivo

@@ -181,6 +181,8 @@
<li><a href="/david/cache/2021/6514143dca5d96bf9e751236b800fba5/" title="Accès à l’article dans le cache local : Are We Really Engineers?">Are We Really Engineers?</a> (<a href="https://www.hillelwayne.com/post/crossover-project/are-we-really-engineers/" title="Accès à l’article original distant : Are We Really Engineers?">original</a>)</li>
<li><a href="/david/cache/2021/4b81d4d9d89fb1d417aa292463529271/" title="Accès à l’article dans le cache local : Vendor by default">Vendor by default</a> (<a href="https://macwright.com/2021/03/11/vendor-by-default.html" title="Accès à l’article original distant : Vendor by default">original</a>)</li>
<li><a href="/david/cache/2021/6ad5b5985682512c140781b2b3c9ff7c/" title="Accès à l’article dans le cache local : That which is unique, breaks">That which is unique, breaks</a> (<a href="https://simonsarris.substack.com/p/that-which-is-unique-breaks" title="Accès à l’article original distant : That which is unique, breaks">original</a>)</li>
<li><a href="/david/cache/2021/e7dd6d41e04bcbf69d3bf09bce827e4c/" title="Accès à l’article dans le cache local : How Long Does It Take to Hire Someone?">How Long Does It Take to Hire Someone?</a> (<a href="https://jacobian.org/2021/mar/11/hours-to-hire/" title="Accès à l’article original distant : How Long Does It Take to Hire Someone?">original</a>)</li>

Escrever Pré-visualização
Carregando…
Cancelar
Salvar