How to use with Browserify?

[ghost]

I am using Browserify to serve my coffee files to the browser.

How do I use contracts with it?

[disnet]

If you're using the latest contracts.coffee (0.2.0 released yesterday) then I think it should "just work". Just use require and the exports object like normal.

I haven't tested it yet though. Have you run into any problems with it?

[ghost]

It emits parsing error:

DEBUG: Error: Parse error on line 261: Unexpected 'PARAM_START'

since it doesn't recognize the contracts code:

exp["add view once"] :: ({name: Str, age: Num}, [...Num]) -> Str
exp["add view once"] = (config) -> ...

That is because Browserify is compiling it with CoffeeScript and not the Contracts

[disnet]

Haven't used browserify before so I'm not totally sure how it works...but is it possible to compile to js first with the contracts compiler and then use browserify?

[ghost]

Sure, but that defeats the purpose of using Browserify to make it simple.

I wished that Coffee supported Contracts out of the box :(

[disnet]

Sure, but that defeats the purpose of using Browserify to make it simple.

Well, it still makes module loading simpler. Use contracts.coffee as compiler and browserify as module loader...separation of concerns and all that. Two lines instead of one in a build script isn't the end of the world IMO.

That said it looks like browserify isn't playing nice with the module wrapping code in contracts.coffee so I'll take a look at that when I get a chance. On a related note I've just checked in preliminary support for require.js modules. So that's another option.

I wished that Coffee supported Contracts out of the box :(

Me too :)

[timhuff]

Has this issue been resolved?

[disnet]

Not really. As you can probably tell by the activity on this project I don't really have time to maintain it these days.

[timhuff]

Ah. Alright. I didn't take that close of a look. Wanted to make sure it worked with browserify before looking deeper.

[lolmaus]

Looking forward to Browserify support.

@disnet While you don't have time to devote to coding to resolve this issue, maybe we can go on with the discussion? I assume that before writing any code that addresses this issue, we have to come up with a conceptual solution.

CommonJS is a standard for organizing your code into modules, used in the NodeJS community. Typcally, you create a lot of files: one per module, and have them require each other. This is very convenient and essential for large JS codebases.

Browserify is a tool that allows using CommonJS for organizing frontend, i. e. code run by browsers. You set Browserify on your frontend's main file, it parses all the required files recursively and concatenates them into a single file that can be delivered to the browser. Browserify takes care of CommonJS syntax to work, of maintaining the correct order of required files, etc.

Browserify can be used by a standalone tool, but there are also two very popular approaches that use Browserify as middleware. One is the Gulp task runner, also NodeJS-based (there are also other popular task runners like Grunt, Brunch, Broccoli, etc). The other one is Sprockets, which is the most popular asset pipeline for Ruby, used in many frameworks (Rails, Middleman, Sinatra, Padrino...), middleware (Rack, Guard...) and preprocessors (Haml, Sass, Less, Jasmine test suite). Sprockets has an extension to support Browserify.

Apparently, the Browserify compiler can't tolerate the Contracts.coffee syntax. We need to come up with a solution that integrates Contracts.coffee into the Browserify workflow, with support for Browserify command-line, Gulp and Sprockets.

I'm gonna ask for advice in Browserify issue queue.

[lolmaus]

@hughsk at browserify/browserify#876 (comment)
You should just be able to write a transform like https://github.com/jnordberg/coffeeify, no need for browserify itself to handle this :)

@disnet, can you please review and confirm that this is a feasible approach?

[disnet]

Yep, writing a transform makes sense to me.

[lolmaus]

@disnet, do you have plans to?

[disnet]

Nope, Sadly no time to work on this for me. Be happy to answer questions if you or anyone else want to take it up though.

[lolmaus]

@disnet, how is Contracts.coffee integrating into the CoffeeScript compiler?

The fact that Contracts.coffee uses the vanilla compiler with an extra flag gives hope that the coffeeify transform can be reused with little modification.

[lolmaus]

@ghost, care to look into this?

[lolmaus]

@disnet, oh, are you bundling your own version of the CoffeeScript compiler?

The original CoffeeScript compiler has made a number of releases and yours seems to be way behind. If Contracts.coffee cannot be used with the original CoffeeScript compiler (rather than its hacked version), then Contracts.coffee can be pretty much considered an abandoned project.

[disnet]

Yeah, contracts.coffee is a fork of the cs compiler. Keeping it up to date with upstream is a huge pain (which is why I saw the macro light and started working on sweet.js).

Abandoned is a pretty good descriptor.