document use of npm shrinkwrap to lock down dialect versions

[darrencruse]

Although the idea of dialects acting as "mixins" that layer on top of other dialects makes for easy extensibility, there's an inherent fragility if dialects you depend on change underneath you.

This has proved especially true as I've been experimenting with different syntaxes and changes during initial development.

My fear is this may always be a challenge though. When typical npm modules you depend on change you may hit a bug that your tests can catch, but when a sugarlisp dialect you "#use" changes it can introduce ambiguities or conflicts that break your compile, or even worse just change your generated code such that your compile doesn't break, but your run time behavior changes and you don't even know why.

Luckily it seems like there's an easy fix(?!) Which is to promote the use of npm shrinkwrap to lock down the versions of the dialects you've developed and tested with so that they won't/can't change until/unless you explicitly retest with the newer versions of the dependent dialects.

i.e. precisely what npm shrinkwrap was meant for!

This issue is just a reminder to document both the problem and how to use npm shrinkwrap to deal with it.