search

sintaxi / terraform

Asset pipeline for the Harp Web Server.
102 stars 101 forks source link

Support CSON. #43

Open sorahn opened 10 years ago

sorahn commented 10 years ago

Support for a CSON files seems to be right up the ally here. And with atom, and github pushing coffeescript and CSON I think we'll be seeing more and more of it.

Cheers.

kennethormandy commented 10 years ago

I started on this, but I think I decided it’s beyond my abilities since it wouldn’t just be a preprocesor. It would have to support harp.cson, _data.cson, etc. But there are failing tests in that branch if someone else wants to take a crack at it.

sintaxi commented 10 years ago

I would hold off on CSON. I think HJSON suits our needs much better.

http://laktak.github.io/hjson/

sorahn commented 10 years ago

@kennethormandy I got all the valid CSON tests passing in my branch. It doesn't support harp.cson yet, but wouldn't you simply be able to edit harp to use terraform to parse it's own config file? Hopefully this helps!

sorahn commented 10 years ago

@sintaxi CSON is currently switching their parser (coffescript) for a static one (cson-safe). Is there any reason to not finish the CSON one and then add HJSON as a 'data' parser too? After that YAML could probably be plugged in as well. YAML isn't really a pre-processor.

kennethormandy commented 10 years ago

Woah, looks promising! Failing tests 1–3 are because I thought CSON would need to error like the other preprocessors: by showing something in the browser. (This stuff happens in lib/javascript etc.)

I supposed you could argue that it should follow what JSON does right now and just fail and throw an error outright. In that case, those tests would need to be different. Otherwise, CSON would kind of need to be implemented in two places: once as a preprocessor and once for the _data.json files, etc.

The last failing test looks related to that. Because you can go examplefile.json.jade to output a JSON file, some part of this implementation is conflicting with that (I think exports.isDataFile is too aggressive)

I’m glad you’re working on this, we seem to have a pretty solid group of people who want whitespace significant everything. I’m definitely onboard, and personally I think adding comments or not breaking when JSON doesn’t have comments doesn’t conflict with adding CSON.

sorahn commented 10 years ago

@kennethormandy OK, I'll probably be able to take another stab at this sometime later this weekend. Feel free to run with some of the work I did if you want to poke around some more.

I've got CSON in 2 places right now, where it's used for _data.json I'm just running it through the regular CSON parser, instead of the render function. Kind of a stop gap to just see if I could get it working. Ideally every parsed file could just be requested through the normal render.

Re: isDataFile, yeah, you're right, I'll clean that up to only match the extension.

valtido commented 9 years ago

@drbrts https://github.com/atom/season I think, this should be simple enough to read a file, then export it as .json. Hope it helps.

rwxrob commented 9 years ago

What's the state of this. I have a course catalog organized as an _data directory that currently I build into _data.json so that Harp serves it properly. Harp handles the .coffeescript and I wonder if building directly into a single .coffee would be better since it gets served up as a single .js file. The goal for me is to just save edits to the individual .cson files and have them be compiled, cached, etc automatically (without any db saves of course).

og2t commented 9 years ago

+1, since CSON is essentially CoffeeScript, it shouldn't be an issue? Or?

vbwx commented 9 years ago

HJSON sounds like a great idea! I'll give it a try this weekend, I think.