A week or so ago James Coglan tweeted this:
It reflects perfectly why I didn’t get too much into Python other than writing isolated scripts that worked well with themselves and didn’t require extra packages, because installing them was a pain and different in each system (compiling, package managers, other package managers, eggs, pip, bla, bla). And then there was the virtualenv solution, but that adds another layer of managing that I have to deal with. I just want to get things done and be able to distribute them in a manner that makes it easy for other people to use my software.
This reminded me that I had to spend a whole afternoon a while ago trying to make some brew-installed packages operate in harmony with other libraries/binaries in my system. It was so tedious and fuzzy I can’t even remember what the problem was actually. Just the notion that installing all the software and making it all available into a global scope === bad, because different versions will require other different versions. And either everything works in harmony and life is beautiful, or you spent a rainy afternoon feeling miserable because of the weather and the incompatible binaries.
tween.js r14 is really more of a “cleaning house” revision than anything else. No new features have been added, but the library should be a little bit more usable now and lead by example by using better code examples that aim to be efficient JS and CSS wise:
- Include license header on the minified files too (hyandell)
- Make examples more efficient by using requestAnimationFrame‘s own timer instead of calling Date.now again (Robert Eisele)
- Make it explicit that you can install tween.js with npm and bower (sole)
As usual, you can download it/clone from github or install with npm:
npm install tween.js
And as a “new thing”, although it was always here, installing via bower is also possible:
bower install tween.js
You can also read more instructions and code samples on getting the library.
Cheers to whoever told me you could install any package using git with bower. I believe it was the magnificent Edna Piranha! So thanks Edna!
TL;WR*: a mostly social event, great for meeting the authors of those modules you see scroll past when you run npm install and it installs half of the internet. Also, lots of presentations on somewhat hipster stuff which I not always understood, but that’s great–I like not understanding it all from the get go, so I can learn something. And some discussion about physical and mental health and better community building and other important non purely technical stuff that usually never gets the chance to be discussed in tech conferences.
npm can do much more than just installing packages and resolving dependencies for installing packages. One of the things it can do is running scripts! You might have seen that already:
It has a series of defaults. For example:
will attempt to run
You can, of course, redefine those defaults by specifying them in the scripts field in package.json. Suppose my script for launching the server doesn’t live in the root of the project, then I’d have to modify the start script entry consequently. Imagine this very minimal package.json:
"start": "node server/main.js"
The defaults can be called with just npm something, and there’s a list of default scripts npm recognises in the script documentation page. Some are very handy because they get called automatically before some scripts are executed. For example, if you run npm test, the pre-test script will also be automatically run before (if it has been specified). You could use that to make sure your bundles are updated before testing them.
If you want to run a script whose key is not one of the defaults, you have to invoke it in a slightly different manner. Suppose it’s specified here in your scripts:
"my-specially-named-script": "echo \"NICE\""
You would then run it with
npm run my-specially-named-script
As you can see it’s not too complicated, and the whole thing is very minimal and obvious, which I like.
If you want to learn more about “advanced” uses of npm and scripts, be sure to read the excellent Task automation with npm run from the always inspiring substack.