A stringify method is exposed but a parse method is missing.

I stumbled upon atom/atom#7763 when looking for an existing issue on this. It seems like the original issue never got to be recreated here, so I would like to do after all.

As season is used by atom for parsing of and writing to config.cson, this means no formatting is preserved after safe. Over time I've hacked on my config quite a lot, and I would really like to add some comments and whitespace here and there to provide some readability.

Example (taken from original issue):

Edited config.cson:

#
# Config
#

'*':
    # --- MAIN ---

    # WELCOME
    welcome:
        showOnStartup: false

    # CORE
    core:
        disabledPackages: [
            'autocomplete-plus'
            'wrap-guide'
        ]
        themes: [
            'one-dark-ui'
            'solarized-dark-syntax'
        ]

    # EDITOR
    editor:
        invisibles: {}
        tabLength: 4


    # --- PACKAGES ---

    # REPORTING
    'exception-reporting':
        userId: 'ddaafd07-dffd-b252-48db-612909a97759'

    # BRACKET MATCHER
    'bracket-matcher':
        autocompleteBrackets: false
        autocompleteSmartQuotes: false

    # WHITESPACE
    whitespace:
        ensureSingleTrailingNewline: false

After saving:

"*":
  welcome:
    showOnStartup: false
  core:
    disabledPackages: [
      "autocomplete-plus"
      "wrap-guide"
    ]
    themes: [
      "one-dark-ui"
      "solarized-dark-syntax"
    ]
  editor:
    invisibles: {}
    tabLength: 4
  "exception-reporting":
    userId: "ddaafd07-dffd-b252-48db-612909a97759"
  "bracket-matcher":
    autocompleteBrackets: false
    autocompleteSmartQuotes: false
  whitespace:
    ensureSingleTrailingNewline: false

Running CSON.readFile on the following CSON results in the callback object's __proto__ being hijacked:

'__proto__':
  toString: 1

Any calls to the object's .toString() method will fail as toString is now an object.

This also has the side effect of preventing season from properly returning __proto__ keys (which can be useful in, for example, snippets).

to be able to do

data = require 'data.cson'

I was looking into https://github.com/JavascriptIsMagic/require-cson/blob/master/register.js
And then I took a look at https://nodejs.org/api/modules.html#modules_require_extensions
And it says Module.extensions is deprecated, and there is better way to do it.

To be more true to the nature of the library (a minimalistic cson parser), we renamed cson-safe to cson-parser. [email protected] was republished as [email protected] without any further changes.

• chmod 000 somefile.cson
• Try to read in somefile.cson

Ideally, I would get an ENOENT error back in the callback.

http://www.fileformat.info/info/unicode/char/2028/index.htm

season is catching an error thrown by one of my callbacks which made debugging a pain.
The offending function is:

parseContents = (objectPath, cachePath, contents, callback) ->
  try
    object = parseObject(objectPath, contents)
    writeCacheFile(cachePath, object) if cachePath
    callback?(null, object)
  catch parseError
    callback?(parseError)

try/catches should be extremely limited in their scope to they only catch errors they want to.
Thus I believe this function needs to be updated to:

parseContents = (objectPath, cachePath, contents, callback) ->
  try
    object = parseObject(objectPath, contents)
  catch parseError
    return callback?(parseError)

  writeCacheFile(cachePath, object) if cachePath
  callback?(null, object)

I'm happy to create a PR with this change and test verifying this behavior if you agree

Due to a problem with my package mocha-ui, I encountered a problem with CSON.writeFile.

I have two watchers on a file from two different atom instances, on change, a cson file is written, potential with different content. Quite often, the resulting file is a combination of both, which is of course invalid cson ;)

One of the files is larger, if this gets written first, then a fragment of the larger file is tailing the smaller file which is written a little bit later.

Maybe rather a problem of fs-plus or fs ?

Inspired by the fact that I have this in my code

CSON.readFile filePath, (err, data) ->
  if err then return done err
  # manipulate data
  CSON.writeFile filePath, data, done

and would like to be able to just write

CSON.updateFile(
  filePath 
  (data) -> # manipulate data
  done
)

CSON.updateFile(objectPath, transform, callback)

Updates the CSON or JSON at the given path.

objectPath - The string path to a JSON or CSON object file.

transform - The function called with the read object and should return the object to be written.

callback - The function to with an error object on failures.

file.json:

{
  "a": 5,
  "b": 6,
  "c-d": 7
}

index.js:

var CSON = require('season');
CSON.writeFileSync('file.cson', CSON.readFileSync('file.json'));

file.cson:

a: 5
b: 6
"c-d": 7

I would prefer to have all keys written as strings, it makes bigger files much easier to read.

CSON.writeFile only writes cson if the file extension ends with .cson and write json otherwise.
I'd prefer it to be the other way around and that is only writes json when the file extension is .json and cson otherwise.

This is a cson library so I think that makes sense. I like the idea of writing being able to convert json to cson (to make it easier for users to convert over) but otherwise don't see any reason to have all this support for json.