Provide a static (non-turing) parser of CSON

[balupton]

As the current parser executes CoffeeScript code (albeit in a node virtual machine), and considering atom.io's use case of CSON, which is leading to more widespread interest than the original developers writing configuration to be executed on their own machines, it could make sense for some efforts to go into writing a static (non-turing) parser of CSON for the purpose of safe execution, opening CSON up to be used in untrusted environments #32

Personally I have no need for such things, as it is outside of my use-case for CSON, however I would happily facilitate and help out in any way I can with such an initiative.

[balupton]

@timaschew considering you're now the frontman of the wonderful js2coffee project, how difficult would you consider this to be? So essentially flipping js2coffee to become coffee2js.

[mhart]

Er... isn't coffee2js just coffee? :-)

I think ideally you'd just want something to only parse the object/primitive portions of CS - ie, everything that lines up with JSON and nothing more. No?

[balupton]

Yeah, I'd hope that coffee just provides this, as it would be fair to expect it to provide such functionality.

[mhart]

Maybe... although... I doubt it. You could certainly use the tokens as a first step, but I doubt much of the compiler or syntax checking... The compiler's there to compile to JS, not JSON - and objects with functions, etc are perfectly valid JS.

So it's just doing things like:

myObj =
  someProp: 'a'
  someOtherProp: 'b'
  someThirdProp: -> "hey I'm a function!"

var myObj = {
  someProp: 'a',
  someOtherProp: 'b',
  someThirdProp: function() { return "hey I'm a function!"; }
};

(I'm not telling you anything you don't already know - just that, you know, a lot more tokens are allowed in the same circumstances for CS/JS that aren't allowed in JSON)

[pluma]

For a ghetto solution you could try running the result of coffee through JSON.stringify (and back). That should take care of the unsafe values for now. It's of course no substitute for a proper parser.

[balupton]

This is true! In the same way we do for js2coffee, we could probably use coffeescript's compile function instead of it's eval function, then with the result, perform some adjustments to make it JSON parseable, and then run it through JSON.parse method to get the result javascript object.

[balupton]

The compile then parse plan is foiled, as coffeescript produces JSON like:

{
  abc: ['a', 'b', 'c'],
  a: {
    b: 'c'
  }
} 

Which isn't valid as JSON requires " around the object keys.

[balupton]

So I've got a hacky version on the static-parsing branch that actually works against our tests, except for test 7, which is a sandboxing test. But as we no longer use sandboxing, we could probably get rid of that test.

[balupton]

I'm going to leave it here for someone smarter than me to submit a pull request for. As it could be the case that the regexes I've done in the static-parsing branch are not the best idea...

[jkrems]

The redux project offers a way to parse coffee-script to an AST. The AST can then be walked and the nodes converted into native objects.

[vendethiel]

We use an AST internally for coffee too (pretty obviously) : see here (without the `.compileToFragments)

[jkrems]

@Nami-Doc Didn't want to imply otherwise. :) Just more familiar with the redux code base and it seemed that it's more "official" in redux by also exposing the AST nodes as csr.Nodes.

[vendethiel]

No, really, that's all implementation details.

[timaschew]

@timaschew considering you're now the frontman of the wonderful js2coffee project, how difficult > would you consider this to be? So essentially flipping js2coffee to become coffee2js.

@balupton that would be very difficult without using coffeescript itself.

[balupton]

Hey everyone, v2 of CSON will be out soon (see it on the "safety-rewrite") branch, which will use cson-safe. Still really dislike the name cson-safe, I wish it was cson-static instead :-( but oh well.

Really excited to get this release out, great work to the cson-safe team! Huge props. I'll send a pull request to your readme with some updated wording (as we will now be using your project) as well as update our readme to link to you.

[jkrems]

Great to hear! Will see that we get a rename going (e.g. to cson-parser). I agree that name will be confusing once the two projects share the same guts.

[jkrems]

Renamed to cson-parser: https://www.npmjs.com/package/cson-parser

[balupton]

:+1:

[balupton]

Fixed in v2

[balupton]

@jkrems how did you get npm to rename cson-safe to cson-parser?

[jkrems]

@balupton By cheating, basically. I changed the name in package.json and then released one last "fake" version of the old package that just contained a README change (https://github.com/groupon/cson-parser/commit/d96425538818889cbb2e573a3548af099a090801). Unfortunately I don't think npm supports renames properly.