craigspaeth/nap

generate sourcemaps

prabirshrestha opened this issue · 6 comments

prabirshrestha commented
generate sourcemaps
bpeacock commented

Just transferring .map files to the final assets directory when available would solve this problem for basic use cases. If you can point me towards a line, I'm happy to contribute a fix to this.

bpeacock commented

This fork has a fix but I'm having trouble getting mocha to process the coffeescript so that I can write tests:

unction (exports, require, module, __filename, __dirname) { require './helpers
                                                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
SyntaxError: Unexpected string
  at Module._compile (module.js:439:25)
  at Object.Module._extensions..js (module.js:474:10)
  at Module.load (module.js:356:32)
  at Function.Module._load (module.js:312:12)

Any thoughts?

craigspaeth commented

Mocha has an update to it's options, so we'll likely need to update test/mocha.opts to look like this https://github.com/artsy/ezel/blob/master/src/cs-clean/test/mocha.opts#L4 with the /register on the end. Thanks for looking into this!

bpeacock commented

That worked!

It looks like the current branch is failing already here:

1) #package when in development mode fingerprints packages:
     AssertionError: expected 'templates-2aa6ea9386ef1fee846015534d13c9ce.jst.js' to include 'templates-81e3c2f5027b4cf4c4e7a48e79c4c430'
    at Object.Assertion.include (/Users/brianpeacock/Desktop/nap/node_modules/should/lib/should.js:548:12)
    at Context.<anonymous> (/Users/brianpeacock/Desktop/nap/test/nap_spec.coffee:594:17)
    at callFn (/usr/local/lib/node_modules/mocha/lib/runnable.js:223:21)
    at Test.Runnable.run (/usr/local/lib/node_modules/mocha/lib/runnable.js:216:7)
    at Runner.runTest (/usr/local/lib/node_modules/mocha/lib/runner.js:374:10)
    at /usr/local/lib/node_modules/mocha/lib/runner.js:452:12
    at next (/usr/local/lib/node_modules/mocha/lib/runner.js:299:14)
    at /usr/local/lib/node_modules/mocha/lib/runner.js:309:7
    at next (/usr/local/lib/node_modules/mocha/lib/runner.js:247:23)
    at Object._onImmediate (/usr/local/lib/node_modules/mocha/lib/runner.js:276:5)
    at processImmediate [as _immediateCallback] (timers.js:330:15)

I'll see if I can catch it while I'm in there fixing what I broke : ). We are using this for production, so I'm wondering if you would be open to setting up some type of CI platform like Travis to catch issues like this in the future? Thanks for your help!

craigspaeth commented

I am definitely interested in setting up Travis. Seems like that spec is just asserting a flimsy condition (does hard-coded hash A == hash B). I'll try to take a look at making the test assert on something more consistent, or will happily accept a PR for that as well.

Sorry for the delay on this, in all honesty we've moved away from this kind of full-solution asset managing at Artsy to a more [modular one](http://ezeljs.com/#asset pipeline). So unfortunately attention to nap has subsided a bit. Still certainly something I'm happy to maintain though, and I'll try to get to this as soon as I can.

bpeacock commented

Travis should be as simple as adding .travis.yml with:

language: node_js
node_js:
  - "0.10"
  - "0.8"
before_script: 
  - npm install -g mocha

I will branch and submit a pull with this, however, you will have to set up the repo on travis and get the badge as the owner. Should be pretty quick though.

Just checked out Artsy, really beautiful site! I'm definitely going to spend some time poking around. As for the asset-management, I agree browserify is a great direction to go, especially if you are including structural css with modular views using something like require-less. But, we're already on Jade/nap for this project, so we'll keep at it!