Switch to cson-safe for parsing

[jkrems]

This uses the approach I outlined in a previous comment for parsing. I removed the test that requires parsing of invalid/unsafe coffee-script as part of a CSON file and moved test 8 to be now test 7. The new parser allows for statically evaluated arithmetic expressions (e.g. myFlag: 1 << 3). If that's a concern, I'd be happy to make it optional. I chose to implement the parsing in its own module since I think that having a minimalistic parsing library that just offers the JSON.{parse,stringify} interface could be valuable to people.

More information about the behavior of the parser:

• parse test in cson-safe
• Error message

[RobLoach]

cson-safe is a fork of cson. This mean that when you download cson, you'll also be downloading a fork of cson. Couldn't we just add the functionality of cson-safe in as an option for cson?

Instead of adding package ontop of package, add functionality to the existing package.

[jkrems]

I'm not sure why you linked to clyfe/cson.npm for cson-safe. That's not the repository of cson-safe. cson-safe lives under https://github.com/groupon/cson-safe/ and is not a fork of or shares any code with this repository. As for the explanation why I thought that creating a minimalistic parser is better: having a project that just focusses on the parsing, without added functionality like loading from files, increases reusability. For example it could make it possible to switch atom/season to the same parser without piling similar modules on top of each other.

[ageitgey]

@RobLoach

We didn't want to replace cson or use any of it's code. I think you were just looking at the wrong repo.

Jan's goal was to implement a very slim, simple cson parsing engine that could be included in any other project that needed safe parsing and wanted to provide features on top of that. It's sort of like how request provides extra features on top of http to make it more usable for developers.

Maybe we should have called it safe-cson-parsing-core instead. That might have been a better name.

[RobLoach]

Ah, got it. I don't know where I got that link. It's this one, correct?
https://www.npmjs.org/package/cson-safe

[jkrems]

Yep, that's the one. :)

[pflannery]

This looks good. I would like to see cson being json's equal too.
Looking at the code we could drop the require to coffee-script and also move coffee-script to a devDependency.

Although, one thing to look out for is projects like docpad where it uses cson to parse docpad.coffee which uses functions. This change would break those projects and they would need to change over use coffee-script parsing directly.

@balupton what say thee?

[jkrems]

Moved coffee-script to devDependencies, did a smoke test with npm install --production and require('./'); in the repl.

[balupton]

+1 for having safe cson in cson

The question is naming. As this repo is the most official cson, I wonder if it's worthwhile moving safe cson here and renaming this repo to cson-extras.

Otherwise, static cson is more appropriate (and dare I say more respectful) name than safe cson ;-)

[jkrems]

In retrospect cson-parser would have been a better project name for cson-safe. If you feel strongly about it, I can change the name. Though that would mean also updating season and grunt-cson which already refer to the current name.

[jkrems]

Just checking in to make sure I'm not currently the blocker on this. :)

[balupton]

Sorry, had some health issue recently. All better now. What is your npm username? I'll add you as a maintainer, as you'll be the best person to merge this in and release it :)

[jkrems]

No worries, hope you are better now! :) Name on npm is also jkrems.

[jkrems]

Rebased on latest master & updated cson-safe version to 1.0.0. Working on a PR to cson-safe to make stringify match more closely the current behavior.

[johan]

Maybe add back the removed newline, to match the other test files?

[jkrems]

The newline wasn't actually removed, this is what previously was 8.json.

[johan]

Ah, got it.

[balupton]

Fixed in v2