author npm modules fast
Are you sure?
- State the problem.
- Has it already been solved?
- No? Proceed.
The #1 rule for writing UNIX modules
philosophy has opinions
Get a drawing room
cd ~/Desktop && npm install drawing-room && mv node_modules/drawing-room ~/Desktop && mv node_modules ~/.Trash && cd drawing-room && npm install && mate .
- What is it? read, play, draw, write
- Determine what preexisting + non-existent modules are needed
- Draw ––>nonJS ––>pseudoJS
- Engineer. remember to
tape, README, git, npm
substack's approach (link)
Now SUBSTACK doesn't do that. He just wants the most dependable, easy to understand and smallest module he can find (or make) to fulfil his objective.
In other words, he subscribes to the UNIX philosophy.
To him, it's about taking the time to understand the abstractions.
- SUBSTACK codes as usual:
- Uses console.dir alot to inspect & debug
- DIDN'T TDD - CREATES AN EXAMPLE.JS THAT REQUIRES THE MODULE AND TESTS ITS FUNCTIONALITY
- Codes in vim & switches to a terminal every so often to run the example.js script
- IF HE NOTICES AN OPPORTUNITY TO MODULARISE, HE IMMEDIATELY MOVES THE FUNCTION INTO A NEW FILE & CHANGES THE FUNCTION DECLARATION TO MODULE.EXPORTS = ... (WHEN I SAY IMMEDIATELY, I REALLY DO MEAN IMMEDIATELY).
- When he's happy with the module,
npm install tape tap --save-dev (own note: added
- Refactors the example.js file as a set of tests (see below).
- Writes README.markdown from scratch with introduction, API documentation & license (API documentation is quick & easy to write when you have small modules).
- Runs pkginit to create package.json. (own note: i run pkginit as the first step)
- Create GitHub repo and npm publish