Namespace Files

[coreyward]

Because you're not namespacing the bootstrap partials, you're causing collisions with existing codebases.

Example:

@import "bootstrap"
@import "mixins"; // my mixins, at least, it *was*

body {
  custom-mixin('foo'); // FAIL, because my mixin file was never imported
}

It would make a lot more sense for each of the bootstrap partials you have to be prefixed with "bootstrap_".

[hardfocus]

Ken Collins' comments about namespace on Pat Shaughnessy's article are well worth reading. http://rubysource.com/twitter-bootstrap-less-and-sass-understanding-your-options-for-rails-3-1/

[hardfocus]

Sorry Corey, maybe I should have been more specific:

For what it's worth, what Ken said was:

[...] I predict that as the asset pipeline gains more adoption, people will learn that there assets need to be namespaced (via directories) just like we are used to our gems and models. So you are free to happenstantially make your own variables.less file in your assets path and never worry about it conflicting with twitter/bootstrap/variables.less. No other gems that I saw are thinking about this potential problem we will face and eventually gem authors will start to understand the importance of namespacing their assets. Because of this the recent less-rails-bootstrap tries to follow a convention I found in Sass/Compass where the path to the raw source files are in a vendor/frameworks directory, which I use less-rails to make sure is in the renderable paths for less.

[coreyward]

@hardfocus Thank you — very good snippet indeed. Good to have the opinions of someone as respected as Pat backing this issue up.

[yury]

I think I'll namespace files in next release. New tw bootstrap will be released very soon.