polidog

task("pre:compile", function(event,logger) {
  var wrench = require("wrench"),
      fs = require("fs"),
      jade = require("jade"),
      path = require("path"),
      coffee = require("coffee-script"),
      stylus = require("stylus");

  event.alloyConfig.coffee = [];
  event.alloyConfig.jade = [];

umi-uyura

"use strict";

task("pre:compile", function(event, logger) {
  var wrench = require("wrench"),
      fs = require("fs"),
      path = require("path"),
      jade = require("jade"),
      styl = require("stylus"),
      view_root = event.dir.views,
      style_root = event.dir.styles;

kitten

With styled-components into the future

Preprocessing is dead, long live preprocessing!

This is a CFP for ReactiveConf 2017's open call for Lightning talks. If you'd like to see this talk become a reality, please ⭐ star this gist. #ReactiveConf

alfredringstad

Forking a single package in a monorepo

The trend of using monorepos makes a lot of things easier to manage. However, when you want to fork a single package inside a monorepo, you'll have to chose one of two options:

• Fork the entire monorepo (meaning you get all those extra boilerplate you don't really care about)
• Manually copying the package files into a new git repo (meaning you'll loose all git history and have a lot of work to do when there's a new version of your base package)

The good news: There's a solution for this! And it's actually built in to git.

git subtree

One of the lesser-known (and vaguely documented) features of git is subtree. It's intended for this purpose, working as a great alternative to the criticized submodules. There are very few resources about using this in practice, so here's a guide for this specific use case.

threepointone

On implementing a client for feature flags in your UI codebase

This document isn't an explainer on Feature Flags, you can find that with my amateur writeup, or literally hundreds of better writeups out there.

This document is also agnostic to the choice of service you'd use: LaunchDarkly or split.io or optimizely or whatever; that's orthogonal to this conversation.

Instead, this document is a list of considerations for implementing a client for using Feature Flags for User Interface development. Service providers usually give a simple fetch and use client and that's it; I contend that there's a lot more to care about. Let's dive in.

To encourage usage, we'd like for the developer experience to be as brutally simple as possible. So, this should be valid usage: