调试Rails资产管道的最佳实践 [英] Best practices for debugging the Rails asset pipeline

问题描述

我正在使用Rails 3应用程序bootstrap-sass和资产管道，并且正在寻找有关如何调试资产管道问题的一些想法.

I'm working with a Rails 3 app, bootstrap-sass, and the asset pipeline, and I'm looking for some ideas on how to debug asset pipelines woes.

在开发中并进行即时编译(即包括从许多已编译的CSS文件中进行编译)时，我的应用看起来完全符合我的期望.

When working in development, and compiling on the fly (i.e. including from lots of compiled css files), my app looks exactly how I expect it to.

但是，当我使用资产管道将资产编译为单个文件以测试其在生产中的行为时，我认为级联文件application.css中的验证错误会导致浏览器停止正确评估css，并且我看到了很多显示问题.

However when I use the asset pipeline to to compile assets into a single file, to test how it will behave in production, I think validation errors in the concatenated file application.css are causing browsers to stop evaluating the css correctly, and I'm seeing a number of display issues.

当我查看开发中生成的css文件并将其通过css3验证器传递时，我可以看到在使用供应商的css文件时会发生验证错误(在大多数情况下，这是由于供应商特定的黑客行为引起的，验证器)-当我通过w3c验证器运行它们时，我生成的文件正在通过验证，并且我在下面的链轮文件中列出了通过/失败结果:

When I look at the generated css files in development, and pass them through a css3 validator, I can see that validation errors occur when working with the vendored css files (in most cases these are due to vendor specific hacks, setting off the validator) - the files I've generated are passing validation when I run them through the w3c validator, and I've listed the pass/fail results in the sprockets files below:

/*
 * sprocket file in application.css
 *
 *= require_self
 *= require vendor
 *= require bootstrap-include # FAILS 474 ERRORS - presumably down to css hacks
 *= require DT_bootstrap      # FAILS TWO ERRORS - presumably down to css hacks again
 *= require navbar            # PASSES
 *= require footer            # PASSES
 *= require main              # PASSES
 *= require home              # PASSES
 *= require widget            # PASSES
 *= require search            # PASSES
 *= require devise            # PASSES
 *= require doohickeys        # PASSES
 *= require datepicker        # FAILS - again yet more cross browser css hacks suspected
*/

当串联中断应用程序的视觉效果时，如何开始准备生产文件?

我在这里要求了解如何最好地调试这样的已编译样式表-听起来好像以前已经优雅地解决了一些问题，但是当我处理一个样式表时我不知道可靠的方法这样的问题.

How should you start prepping files for production when concatenation breaks an app's visuals like this?

I'm asking on here to get an idea of how best to debug a compiled stylesheet like this - it sounds like something that has been solved before elegantly, but I'm not aware of a reliable, approach when dealing with a problem like this.

例如，我可以看到某些规则没有通过Firefox和Webkit中的Web开发人员检查器工具进行评估，但是我不清楚如何超越此范围，因为对已编译的CSS进行了一些费力的二进制搜索

For example, I can see that some rules are not being evaluated by using web developer inspector tools in Firefox and Webkit, but it's not clear to me how to go beyond that, short of doing some laborious binary search on the compiled CSS.

当然已经有一些专门的工具可用于这种情况，例如仅能够编译application.css中的某些文件，并分别链接到预编译的bootstrap-sass文件，或者类似的东西?

Surely there are some more specialised tools available for situations like this already, like being able to compile only some files in application.css, and link to a precompiled bootstrap-sass file separately, or something similar?

推荐答案

如果您正在使用bootstrap-sass之类的东西，则不应使用Sprocket指令，而应使用@import.

You should not use Sprocket directives if you are using something like bootstrap-sass, you should use @import.

将清单文件从application.css重命名为application.css.scss，然后从@import重命名，例如:

Rename your manifest file from application.css to application.css.scss, then @import away, example:

@import "frameworks";
@import "bootstrap-responsive";

这篇关于调试Rails资产管道的最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！