documentcloud / jammit

Industrial Strength Asset Packaging for Rails
http://documentcloud.github.com/jammit/
MIT License
1.16k stars 197 forks source link

Allow more environments than development to have packaging disabled #73

Closed Mange closed 13 years ago

Mange commented 13 years ago

We're trying to have cucumber running with env-js, which means that it will evaluate JS when it sees it. Packing all JS and CSS for every cucumber run makes the runtime unbearable, and when any errors occur we have useless variables and line numbers to work with.

I propose having a config option where you can specify which environments packing is disabled in so that we might disable on development, test and cucumber.

jashkenas commented 13 years ago

Mange: JavaScript packaging and compression is already disabled by default in all environments apart from production. Can you gist the contents of your assets.yml, so I can take a look at what's going wrong?

Mange commented 13 years ago

Sorry for my delayed reply. I had already left the office. The only setting (besides the listing of files to use) is javascript_compressor: closure

When I run cucumber and save the generated HTML, the include tags are all pointing to /assets/<package>.js.

I could send you most of the output if you'd think it would help.

Mange commented 13 years ago

BTW, they are all pointing to the filesystem and not to the Jammit controller. Unless I precache them on the disk, no styling will be present in the generated html.

Mange commented 13 years ago

Another update. The reason it linked to the filesystem was that this is the way capybara generated the HTML file. It's not something that is related to Jammit.

If I add package_assets: off, the test runs 30 seconds faster and the layout contains all the separate JS/CSS files instead of the packaged ones.

Another proof of packaging happening is that the closure generated JS have some encoding issues while the separate files work like they should in EnvJS. This is, of course, unrelated to this issue and is a problem on our end, but evidence nonetheless. :-)