In terms of js/css/img type assets, is there a way to serve everything you have in "web" and "lib" regardless of whether or not you used it in your HTML?
Also, maybe put that small bit in bold in the documentation...It took me FOREVER to figure out pub serve only included files that were actually used in the HTML.
I tried the --all flag, but that didn't seem to work.
You may ask why? Because isn't it so awesome that Dart is so smart in that it only includes what you use? Well yea if it actually worked and was so simple that'd be great...But the problem is it while it parses the HTML and that's all well and good...Other JS files could themselves depend on assets. Pub serve doesn't go that deep. Plus, AJAX loading, etc. I just want all my assets. I put them there for a reason. I really dislike how Dart assumes certain things.
I suspect it has something to do with transformers and perhaps I could have my own...and I'm looking into that now, but is there something I'm missing?
Thanks!
Related
I've got this angular/rails app going, I had been previously been playing around with vim-coffee plugins to watch my files and compile, I was using it to debug. Now, I feel like there is some residual behavior that is compiling the coffee files into .js.js files right in same folder. I'm not enjoying this behavior, though it isn't impacting the app itself. What should I be doing to address this? Actually, looking at this further, this is happening across all my coffee files in this application, as far as I can tell, it isn't happening in other projects.
This has nothing to do with vim or rails in particular; it's just that the CoffeeScript compiler will only look at the file extension (.coffee). Any other part of the file is preserved. So you have x.js.coffee and it gets compiled to x.js.js because .coffee -> .js. This could be anything like x.foo.bar.coffee would become x.foo.bar.js by nature of the compiler.
As you said this has no effect on the app itself, so I would just ignore it. The generated files shouldn't even be tracked as part of your project.
yeah, so apparently I had put
autocmd BufWritePost *.coffee silent make!
into my ~/.vimrc and that was autocompiling coffee files, all I had to do was comment it out. so not really a vim issue, more of a user settings configuration question but thank you all for the input and effort.
I have the following files, in my asset path:
javascripts/abc.js
templates/abc.js.mustache # this gets compiled to abc.js
naturally, they both would be requested as assets/abc.js.
Is there a fix? If not, what part of the Sprockets source would need to be modified?
My thinking is along the lines that if the engine can remove the extension, it can well enough add a suffix.
It may be too obvious, but isn't it better just rename files? I understand nature of your question, but it's hard to imagine ultimate requirements, which forces same filenames for those files. Hence this, you have foobar.js and foobar.js.mustache, which compiles to foobar.js. Why they have same names? They do same things? This is design flaw, if you ask me.
I have the same problem, and have not yet found a satisfying solution. My sites have many complex full-stack plugins (aka engines), and they have lots of css, js, and image files. Having to namespace, eg "styles.css" in each plugin kinda sucks. When upgrading to Rails 3, I assumed the file resolver would put engines/plugins in /styles, but no, they all get combined into one virtual path.
My current temporary solution is to build a rake task that I run that checks for duplicate filenames. I run it before committing code and on deployment. Hackity! If that helps, great, if not, perhaps someone out there has a more elegant solution...
I am working on a project that needs to alter Refinery's WYMEditor behavior a bit. This is easily done by overriding jquery.refinery.wymeditor.js using rake refinery:override and editing it to my own needs, which works fine in development environment.
However, when it comes to production, overrides are ignored. That is, the compiled asset just contains jquery.refinery.wymeditor.js from bundle, and editing that file directly there may give the desired effect, but that's just not the way it should be done.
Strange thing is, that the problem apparently manifests itself only when trying to override backend-related assets.
It might be useful to know that I am using refinery-edge.
Any help appreciated.
So I have managed to beat it. First thing to mention is that it wouldn't be possible without poking into Refinery source code.
As I have already written in the comment, the problem was that I was trying to override an asset (wymeditor/jquery.refinery.wymeditor.js in my case) that wasn't included in a view directly, but was referenced in another asset, which was taken from the gem. And since sprockets knows nothing about Refinery's overrides, it took the referenced assets by the relative path, i.e. from the gem (and hence, unmodified), too. So, again, in my case the solution was to override the refinery/wymeditor.js, and everything worked as a charm.
Should you need to change any other backend script than WYMEditor, you will most likely have to override the refinery/refinery.js, which includes all other backend scripts, in addition to the very script you need to modify.
There is one big concern, though. With all these overrides, I have made any updates very error-prone, since some files will update, and some will not. It could have been avoided by overriding everything, but that effectively means no updates at all.
Try changing the name of the generated file and including that in your manifest instead of the original name. I suspect that it is preferring the original in the presence of two assets named the same thing.
I understand that partials in compass do not create a separate .css file. But I don't understand when/why would I ever want to use this?
Mostly just for organization and separation of logical pieces of CSS. For example, I keep a _reset.scss that I can paste into any project, then have things like _layout.sass, _homepage.sass, etc. They all get shoved into a single compiled CSS file (so I don't have to deal with multiple HTTP requests), but I can get to the styles for any given piece of a project quickly and easily.
we are working on a large web application with Rails for quite a while and produced a lot of css for our templates. Stylesheet definitions are organised in a bunch of css files that have grown with the project. As people are not always as disciplined as they should be, it seems to me that a lot of definitions have become deprecated and useless.
Is there an (semi-)automatic way to get rid of this stuff? How do you identify useless css in your project?
You can use the Dust-Me Selectors plugin for Firefox or the CSS redundancy checker.
Both are great tools that I use often and they save you hours of searching and deleting.
Another tool worth making note of also is the CSS Tidy open source project. This minifies your CSS, especially useful in these cases when you have a huge site with a huge CSS file :)
I believe the sourcecode for the CSS Redundancy checker can be found here. Ran it through the JSLint plugin at jsFiddle.net but gave me some errors, saved it for everyone here.
Not exactly a 'rails' solution but you don't always need one. I use the Dust-Me Selectors firefox plugin to find unused selectors. Works for me.
edit: kyle beat me to it
We didn't have a particularly large CSS file (about 3500 lines) and we found it sufficient to grep the codebase for each selector. (Obviously this can be semi-automated with shell pipes, xargs and friends).
Following this process, we ended up deleting a few too many CSS styles, thanks to some of our CSS style names being dynamically generated (a bad idea in retrospect).
For more detail about our workflow and results, I co-wrote a few thousand words about our experience turning the CSS from a Rails 2.x app into an asset pipeline ready, responsive and modular Rails 4.2.x SASS setup.
CSS Refactoring: From append-only to modular CSS