Tuesday, March 07, 2017

npm3 Shenanigans

I'm beginning to see why people hate npm. Both npm-shrinkwrap and npm3's dependency deduping are terrible ideas. npm-shrinkwrap is meant to solve a problem that has to do with programmers incorrectly using semver to specify dependency versions, thereby encouraging programmers to keep incorrectly using semver and putting an ever-expanding bandaid on it, rather than fixing the actual problem. npm3's dependency resolution fixes a problem that npm never had, with a poorly designed feature that is way outside of npm's scope. Instead of including all sub-dependencies with the package that requires them, like npm2 did, npm3 will attempt to merge the dependency trees. This means that the resulting dependency tree will differ depending on install order. "Does this matter? No!" says the documentation; except it totally does: 1) Some problematic package installs become intermittent, 2) The size of the install is sort of arbitrary, and 3) Don't tell me you've never edited a source in node_modules for debugging purposes; now these will (maybe/sometimes) affect all the subdependencies that also use the same module, making it that much harder to debug. Luckily, npm3 still allows you to specify --legacy-bundling to avoid automatic deduping entirely. Keeping my fingers crossed that they will keep this option indefinitely. As for npm-shrinkwrap, just don't use it! If a dependency doesn't use semver correctly, either don't use that dependency, file a critical bug, or fork it and fix it yourself.

Friday, August 22, 2014

L00k, I haz JavaScriptz!!! ô-ô

I recently published several JavaScript libraries. Some not so recently:)

#1. Freemason

https://www.npmjs.org/package/freemason
https://github.com/spikesagal/freemason

A build utility that is super-simple to use and doesn't require any configuration. Here's an example:
var build = require('freemason').tasks;
build.concatenate('LAB.src.js','jsrequire.src.js');
build.minify();
build.attribute('src/credits.txt');
build.write('dist/jsrequire.min.js');

#2. Require

https://github.com/spikesagal/require

Client-side asynchronous script importing, built on top of LABjs. Here is an example:
var YourModule = require('/path/to/your_module.js', function() {
  YourModule.executeFunction();
});

#3. Wedge

https://github.com/spikesagal/wedge

A browser compatibility shim. Currently supports IE 8+.

#4. TemperSynth


A musical synthesizer with dynamically controlled scale temperament. This was my music hackathon project @ Spotify.

Sunday, December 01, 2013

Client-side JavaScript Module Loading

Thank you Tom Dale for pointing out why RequireJS completely misses the point of requiring modules. While I agree with that assessment, there are better ways to store (unparsed) functions than as strings.

I am still hoping to find a library that takes a healthy approach to implementing require functionality for client-side JavaScript. If I don't find anything soon though, I will have to make one myself. Here are the key aspects I will require of... require:

  • Modules should be stored unparsed until required.
  • A require command will be null code if the module had already loaded.
  • A require command will parse the module and append it as a property of the current scope if it had not yet been loaded but is available to the client.
  • A require command will attempt to retrieve the module file via AJAX if it is not available to the client.
  • A require command will throw an error if the module is unavailable on both the client and the server.
  • The same require command will be parsed by the packager on the server side to compile the module into the distribution file.

Now back to my quest...