Again, as requested, a separate pull request for the yaml parser switch.
I agree with you: it shouldn't break existing users. At the same time: The other yaml parser is just.. better. So if users switch to it, they shouldn't have any problems with their .yaml files.
The only thing they have to do, is to install the other yaml parser.
If you want I can check if there's a nice way to check if either of the yaml modules is installed, thus not braking backwards compatibility.
PS.: I based this pull request on the other one, since you said you wanted to pull it in anyway.
Added a test for the environment.
The config now parses local.EXT and local-deployment.EXT files as well.
Also added tests for it.
Switching from visionmedia/js-yaml to nodeca/js-yaml.
The nodeca parser is a lot more elaborate and stable.
Added the js-yaml module and made sure the tests pass.
Added the Visionmedia YAML parser as fallback for backwards compatibi…
Ok.. So I added the Visionmedia YAML parser as fallback if the nodeca parser isn't available.
I haven't found a better way than to simply catch the require() exception.
Is there any reason you didn't pull this in yet? Are you not convinced that nodeca's yaml parser is better? Or is there something wrong with my request?
Apologies for taking so long to merge this. I'll get a new version published to npm shortly.
No problem! I have pending pull requests for weeks sometimes before I have the time to merge them. I just wanted to make sure that everything was OK.