jeromecoupe

"use strict";

// Load plugins
const autoprefixer = require("autoprefixer");
const browsersync = require("browser-sync").create();
const cp = require("child_process");
const cssnano = require("cssnano");
const del = require("del");
const eslint = require("gulp-eslint");
const gulp = require("gulp");

gricard

If you enjoyed reading this, I'm intending to do more blogging like this over here: https://cdgd.tech

This is not a complaint about Webpack or v4 in any way. This is just a record of my process trying it out so I could provide feedback to the webpack team

Hmm... I don't see any docs for 4.0 on https://webpack.js.org. I guess I'll just wing it. All I need to do is npm i -D webpack@next, right?

+ webpack@4.0.0-beta.2

kevinweber

<alignment jcr:primaryType="nt:unstructured"
    name="./alignChildren"
    fieldLabel="Alignment of components"
    required="{Boolean}true"
    selectionMode="single"
    sling:resourceType="granite/ui/components/coral/foundation/form/buttongroup">

    <items jcr:primaryType="nt:unstructured">
        <default jcr:primaryType="nt:unstructured"
            name="./default"

odewahn

I really liked @tjvantoll article Handling Failed HTTP Responses With fetch(). The one thing I found annoying with it, though, is that response.statusText always returns the generic error message associated with the error code. Most APIs, however, will generally return some kind of useful, more human friendly message in the body.

Here's a modification that will capture this message. The key is that rather than throwing an error, you just throw the response and then process it in the catch block to extract the message in the body:

fetch("/api/foo")
  .then( response => {
    if (!response.ok) { throw response }
    return response.json()  //we only get here if there is no error
 })

timothyis

// Gulp module imports
import {src, dest, watch, parallel, series} from 'gulp';
import del from 'del';
import livereload from 'gulp-livereload';
import sass from 'gulp-sass';
import minifycss from 'gulp-minify-css';
import jade from 'gulp-jade';
import gulpif from 'gulp-if';
import babel from 'gulp-babel';
import yargs from 'yargs';

tracker1

Directory structure for JavaScript/Node Projects

While the following structure is not an absolute requirement or enforced by the tools, it is a recommendation based on what the JavaScript and in particular Node community at large have been following by convention.

Beyond a suggested structure, no tooling recommendations, or sub-module structure is outlined here.

Directories

• lib/ is intended for code that can run as-is
• src/ is intended for code that needs to be manipulated before it can be used

0gust1

var extname = require('path').extname;
var Metalsmith = require('metalsmith');
var myth = require('myth');
var http = require('http');
var templates = require('metalsmith-templates');
var markdown = require('metalsmith-markdown');
var watch = require('metalsmith-watch');

/**

andrewdc

var gulp = require('gulp'),
    gutil = require('gulp-util'),
    sass = require('gulp-sass'),
    rubysass = require('gulp-ruby-sass'),
    fileinclude = require('gulp-file-include'),
    rename = require('gulp-rename'),
    notify = require('gulp-notify'),
    livereload = require('gulp-livereload'),
    lr = require('tiny-lr'),
    connect = require('gulp-connect'),

samwize

// # Mocha Guide to Testing
// Objective is to explain describe(), it(), and before()/etc hooks

// 1. `describe()` is merely for grouping, which you can nest as deep
// 2. `it()` is a test case
// 3. `before()`, `beforeEach()`, `after()`, `afterEach()` are hooks to run
// before/after first/each it() or describe().
//
// Which means, `before()` is run before first it()/describe()

jareware

⇐ back to the gist-blog at jrw.fi

Advanced SCSS

Or, 16 cool things you may not have known your stylesheets could do. I'd rather have kept it to a nice round number like 10, but they just kept coming. Sorry.

I've been using SCSS/SASS for most of my styling work since 2009, and I'm a huge fan of Compass (by the great @chriseppstein). It really helped many of us through the darkest cross-browser crap. Even though browsers are increasingly playing nice with CSS, another problem has become very topical: managing the complexity in stylesheets as our in-browser apps get larger and larger. SCSS is an indispensable tool for dealing with this.

This isn't an introduction to the language by a long shot; many things probably won't make sense unless you have some SCSS under your belt already. That said, if you're not yet comfy with the basics, check out the aweso