akshar100

YUI.add('mojito-session-addon', function(Y, NAME) {
  function MojitoSession(command, adapter, ac) {
    // The "command" is the Mojito internal details
    // for the dispatch of the mojit instance.
    // The "adapter" is the output adapter, containing
    // the "done()", "error()", etc, methods.
    // The "ac" is the ActionContext object to which
    // this addon is about to be attached.
    var sessionCookie = ac.cookie.get("sid");
    if(!sessionCookie){

caridy

What is this?

This is a script that you can add to your application to generating yui meta data and compiling yui modules using express-yui and locator. As a result, a build folder will be generated with everything that was compiled.

How does this work?

Locator walks the folder structure for your app, and finds any yui module, including build.json or just traditional *.js files with the corresponding YUI.add() statement. Generating the result of the operation as well as the metadata associated to each module.

Under the hood, it uses shifter to generate almost everything that is needed.

caridy

What is this?

This is a prototype for the low-level api to serialize express routes into the client side.

Installation

npm install
node simple.js
node complex.js

ericf

Proposal for Extending Express Apps

Creating npm packages which extend the functionality of Express apps has become a major thing we've been doing. There are several approaches we can take, from messing with the Express object prototypes, to creating a function in which an express app is passed in. After trying the former, I'm now a fan of the latter.

The Issues with Extending Express

Extending the Express object prototypes has issues. The running Node.js process may have multiple versions of express, and in order to extend the prototypes you need to require('express'). This means that you might get a different express module instance than the one the main app is created from.

Both approaches suffer from extending something more than once. Similar to how there may be multiple version of express in the running Node.js process, there can also be multiple copies of the extension modules. If the app developer needs to rely on a different version of an Express ext

domenic

pr () {
  git fetch origin refs/pull/$1/head:refs/remotes/origin/pr/$1 --force
  git checkout -b pr/$1 origin/pr/$1
  git rebase master
  git checkout master
  git merge pr/$1 --ff-only
}

medikoo

List of ECMAScript 6 shims

Implemented on top of ECMAScript 5

Provided as distinct CJS modules, installable via npm

---

ECMAScript 5 Built-in Objects extensions

Individual modules of es5-ext package. See ES6 features for usage information.

Array

domenic

Practical Implications of Removing module x from "y"

Background

According to this gist, the modules break-out session at TC39 (a subset of the larger committee) decided to remove the

module x from "y";

ericf

SPDY Push for Externalizing Dynamic Inline Scripts for CSP

This is a rough outline of some thoughts on how to leverage [SPDY Push][SPDY] externalize inline <script>s that contain dynamic, page/user-specific configuration and state data to align with [CSP][].

Problem

We are building web apps where the initial rendering (HTML) is built server-side, and in order for the client-side JavaScript app to take over, the app's configuration and initial state are written to an inline <script> element.

WebReflection

// this is now a module:
// https://github.com/WebReflection/backtick-template#es2015-backticks-for-es3-engines--


var template = require('backtick-template');

// just string
const info = 'template';
`some ${info}` === template('some ${info}', {info});

sebmarkbage

var Bar1 = base => class extends base {
  componentWillMount(){
    super.componentWillMount();
    console.log('Bar1');
  }
};

var Bar2 = base => class extends base {
  componentWillMount(){
    super.componentWillMount();