madox2

function ESLintFix()
  write
  silent execute "!./node_modules/.bin/eslint --fix %"
  edit! %
  redraw!
endfunction
command W call ESLintFix()

rstacruz

bundle-js

Batteries-included, minimal-configuration JS bundler

A hypothetical JavaScript bundler. bundle-js aims to be your one-stop-shop for everything in the JS frontend. Goals:

• Batteries-included: you should be able to use bundle-js without any plugins or any fancy configuration.
• Convention over configuration: there should be little need to configure bundle-js.
• One dependency: no more dealing with webpack, loaders, babel, babel presets, babel plugins, and so on!
• Extensible: it should still be possible to extend functionality if necessary.

yoshuawuyts

const reg = new RegExp("([^?=&]+)(=([^&]*))?", "g")

function qs (uri) {
  const obj = {}
  uri = uri.replace(/^.*\?/, '')
  uri.replace(reg, map)
  return obj

  function map (a0, a1, a2, a3) {
    obj[decodeURIComponent(a1)] = decodeURIComponent(a3)

fgui

;; it formats buffer and attempts to return to original position.
(defun cider-format-buffer-back () (interactive)
  (let (p)
    (setq p (point))
    (cider-format-buffer)
    (goto-char p))
  )

(defun add-clj-format-before-save () (interactive)
       (add-hook 'before-save-hook

bmhatfield

# In order for gpg to find gpg-agent, gpg-agent must be running, and there must be an env
# variable pointing GPG to the gpg-agent socket. This little script, which must be sourced
# in your shell's init script (ie, .bash_profile, .zshrc, whatever), will either start
# gpg-agent or set up the GPG_AGENT_INFO variable if it's already running.

# Add the following to your shell init to set up gpg-agent automatically for every shell
if [ -f ~/.gnupg/.gpg-agent-info ] && [ -n "$(pgrep gpg-agent)" ]; then
    source ~/.gnupg/.gpg-agent-info
    export GPG_AGENT_INFO
else

rauchg

require-from-twitter

Since Twitter doesn't have an edit button, it's a suitable host for JavaScript modules.

How to use

Source tweet: https://twitter.com/rauchg/status/712799807073419264

const leftPad = await requireFromTwitter('712799807073419264');

mrmrs

How not to scale css

Several years ago I got curious about how css worked at scale. When I first started out, there weren’t nearly as many learning resources as there are now. CSS zen garden was amazing, at the time it showed how much you could change a design without altering the html.

In the beginning, that’s what people sold me as a feature. By writing css, you could make a change one place and have it propagate everywhere. In principle this sounds pretty good. I’m lazy so I like doing things one time. But eleven years later, my experience on both large and small teams is that this is the most terrifying thing about css.

https://twitter.com/thomasfuchs/status/493790680397803521

In the past few years a lot of very smart people have been thinking more about CSS and this has lead to some fascinating discussions around how to build ‘scalable’ ui and how that relates to CSS. When I first started to think about scalability I naturally started to read every blog post and watch every tech talk I could get

othiym23

About a year and a half ago, I wrote a "periodic update" of the npm CLI road map. Apparently the period is 19 months! Of the 7 high-level items on the list, we've since addressed 3, which I'm going to call "not bad", given that at least one of the things we shipped, which turned out to be npm@3, is probably the most substantial rewrite of npm's core installer since the very early days of the CLI.

improve npm's tests

npm's developers need to trust its tests. They're the single most important signal that a new version of npm is not going to break users' workflows when a new release is pushed out. Unfortunately, we don't, and once we realized that, it became clear that we could no longer put off working on the test suite until we do trust the tests.

Here's the requirements we identified:

1. The tests need to be always passing, not just locally, but in Travis, so we have a way of gauging if your patches are safe to merge.
2. np

idibidiart

Building a Maintainable, Agile Architecture for Realtime, Transactional Apps

A maintainable application architecture requires that the UI only contain the rendering logic and execute queries and mutations against the underlying data model on the server. A maintainable architecture must not contain any logic for composing "app state" on the client as that would necessarily embed business logic in the client. App state should be persisted to the database and the client projection of it should be composed in the mid tier, and refreshed as mutations occur on the server (and after network interruption) for a highly interactive, realtime UX.

With GraphQL we are able to define an easy-to-change application-level data schema on the server that captures the types and relationships in our data, and wiring it to data sources via resolvers that leverage our db's own query language (or data-oriented, uniform service APIs) to resolve client-specified "queries" and "mutations" against the schema.

We use GraphQL to dyn

gabriel-laet

Just an example of how you can make your webpack config more declarative an re-usable.

You can have a generic webpack.config.js that includes most of your common setup (loaders, plugins and all that) and an attribute in your project's package.json (or anywhere you think it makes sense) containing your project's entries or any other setup you might want to change.

• npm start - live reload, http://localhost:8000
• npm run build - build to dist folder
• npm run build -- -p - production build to folder
• npm run watch - watch to dist folder