Chip Castle chip

Better local require() paths for Node.js

Problem

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.

Possible solutions

OBSOLETE

This entire guide is based on an old version of Homebrew/Node and no longer applies. It was only ever intended to fix a specific error message which has since been fixed. I've kept it here for historical purposes, but it should no longer be used. Homebrew maintainers have fixed things and the options mentioned don't exist and won't work.

I still believe it is better to manually install npm separately since having a generic package manager maintain another package manager is a bad idea, but the instructions below don't explain how to do that.

Fixing npm On Mac OS X for Homebrew Users

Installing node through Homebrew can cause problems with npm for globally installed packages. To fix it quickly, use the solution below. An explanation is also included at the end of this document.

How to use Tim Pope’s Pathogen

I’ll assume you are on Linux or Mac OSX. For Windows, replace ~/.vim/ with $HOME\vimfiles\ and forward slashes with backward slashes.

The idea

Vim plugins can be single scripts or collections of specialized scripts that you are supposed to put in “standard” locations under your ~/.vim/ directory. Syntax scripts go into ~/.vim/syntax/, plugin scripts go into ~/.vim/plugin, documentation goes into ~/.vim/doc/ and so on. That design can lead to a messy config where it quickly becomes hard to manage your plugins.

This is not the place to explain the technicalities behind Pathogen but the basic concept is quite straightforward: each plugin lives in its own directory under ~/.vim/bundle/, where each directory simulates the standard structure of your ~/.vim/ directory.

The future is here: Classless object-oriented programming in JavaScript.

Douglas Crockford, author of JavaScript: The Good parts, recently gave a talk called The Better Parts, where he demonstrates how he creates objects in JavaScript nowadays. He doesn't call his approach anything, but I will refer to it as Crockford Classless.

Crockford Classless is completely free of class, new, this, prototype and even Crockfords own invention Object.create.

I think it's really, really sleek, and this is what it looks like:

function dog(spec) {

Douglas Crockford showed a slide showing how he creates JavaScript objects in 2014.

He no longer uses Object.create(), avoids 'this' and doesn't even care about memory reduction by using prototypes.

https://www.youtube.com/watch?v=bo36MrBfTk4 (skip ahead to 35 mins for relevant section)

Here is the pattern described on the slide:

function constructor(spec) {

###Icons

Name	Size
iphone_2x	120x120
iphone_3x	180x180
ipad	76x76
ipad_2x	152x152
android_ldpi	36x36
android_mdpi	48x48

	-- #t behaves strangely with hashtables & nil values
	function table_length(t)
	local count = 0
	for _ in pairs(t) do count = count + 1 end
	return count
	end

	function Test(test, expectation)
	return {
	test = test,

	" Ag replace
	function! ProjectAgReplace(search)
	silent execute "args `ag -l " . a:search . "`"
	let repcmd = "%s/" . a:search . "/"
	let replace = input(repcmd)
	execute "argdo" repcmd . replace
	endfunction

	#lang racket/base

	; One way to define a logger
	(define lg (make-logger 'my-logger))
	; Define a receiver for this logger, along with a log level
	(define rc (make-log-receiver lg 'error)) ; also try with 'debug

	; Another way to define a logger, with additional forms
	(define-logger lg2)
	(define rc2 (make-log-receiver lg2-logger 'debug))

	if _, err := os.Stat("/path/to/whatever"); os.IsNotExist(err) {
	// path/to/whatever does not exist
	}

	if _, err := os.Stat("/path/to/whatever"); !os.IsNotExist(err) {
	// path/to/whatever exists
	}