cd ~/Library/Application\ Support/Sublime\ Text\ 2/Packages
git clone git://github.com/jashkenas/coffee-script-tmbundle CoffeeScript
git clone https://github.com/miksago/jade-tmbundle.git Jade
git clone https://github.com/LearnBoost/stylus.git Stylus
/* Based on http://kevinburke.bitbucket.org/markdowncss/ */ | |
body{ | |
margin: 0 auto; | |
font-family: Georgia, Palatino, serif; | |
color: #444444; | |
line-height: 1; | |
max-width: 960px; | |
padding: 30px; | |
} |
function git_prompt_info() { | |
ref=$(git symbolic-ref HEAD 2> /dev/null) || return | |
echo "$ZSH_THEME_GIT_PROMPT_PREFIX${ref#refs/heads/}$ZSH_THEME_GIT_PROMPT_SUFFIX" | |
} |
The question: how can we use ES6 modules in Node.js, where modules-as-functions is very common? That is, given a future in which V8 supports ES6 modules:
- How can authors of function-modules convert to ES6
export
syntax, without breaking consumers that dorequire("function-module")()
? - How can consumers of function-modules use ES6
import
syntax, while not demanding that the module author rewrites his code to ES6export
?
@wycats showed me a solution. It involves hooking into the loader API to do some rewriting, and using a distinguished name for the single export.
This is me eating crow for lots of false statements I've made all over Twitter today. Here it goes.
When the directory structure of your Node.js application (not library!) has some depth, you end up with a lot of annoying relative paths in your require calls like:
const Article = require('../../../../app/models/article');
Those suck for maintenance and they're ugly.
# set prefix to control-f | |
set -g prefix C-f | |
#unbind system defined prefix | |
unbind C-b | |
# helps in faster key repetition | |
set -sg escape-time 0 | |
# start session number from 1 rather than 0 |
The final result: require() any module on npm in your browser console with browserify
This article is written to explain how the above gif works in the chrome (and other) browser consoles. A quick disclaimer: this whole thing is a huge hack, it shouldn't be used for anything seriously, and there are probably much better ways of accomplishing the same.
Update: There are much better ways of accomplishing the same, and the script has been updated to use a much simpler method pulling directly from browserify-cdn. See this thread for details: mathisonian/requirify#5
This is a set up for projects which want to check in only their source files, but have their gh-pages branch automatically updated with some compiled output every time they push.
A file below this one contains the steps for doing this with Travis CI. However, these days I recommend GitHub Actions, for the following reasons:
- It is much easier and requires less steps, because you are already authenticated with GitHub, so you don't need to share secret keys across services like you do when coordinate Travis CI and GitHub.
- It is free, with no quotas.
- Anecdotally, builds are much faster with GitHub Actions than with Travis CI, especially in terms of time spent waiting for a builder.