search

craigspaeth / nap

Compile, manage, & package stylesheets, javascripts, and javascript templates for node.js
MIT License
122 stars 33 forks source link

generate sourcemaps #64

Closed prabirshrestha closed 10 years ago

bpeacock commented 10 years ago

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 10 years ago

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 10 years ago

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 10 years ago

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 10 years ago

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 10 years ago

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!