Hi Flori, can you provide some details about what problems are you having replacing Sprockets in Rails apps?
In new apps you can disable Sprockets with --skip-sprockets flag: rails new foo --skip-sprockets in existing apps you need to edit the config/application.rb file and comment this line: # require 'rails/all' And instead require the frameworks you want to use: require "active_record/railtie" require "action_controller/railtie" require "action_view/railtie" require "action_mailer/railtie" require "rails/test_unit/railtie" # require "sprockets/railtie" # comment to disable sprockets That's the same procedure people use to replace other components like ActiveRecord with alternatives like Mongoid. Best Regards. On Wed, Jun 11, 2014 at 11:25 AM, Joe Fiorini <[email protected]> wrote: > As the creator and maintainer of Half Pipe, I feel I should weigh in here. > I agree with the overall sentiment here that it is not ready to be a > general-purpose Sprockets replacement, nor am I convinced that it should > be. Obviously I have some opinions around using Sprockets, but at the end > of the day the Rails asset pipeline got people talking/caring about better > asset management, which is what matters most. > > I do believe that the Asset Pipeline is currently a little short-sighted. > The term itself is a misdirection, as "Asset Pipeline" really means > "Sprockets". In order to use anything else, you are essentially > monkey-patching, which is what the whole Rails/Merb merge was trying to get > rid of. To make something else the default in Rails only exacerbates that > problem, it doesn't solve it. I would rather see easier ways to hook into > the asset pipeline with our own tools, and make Sprockets optional. I have > only just begun to think of what that would look like, so I unfortunately > can't propose anything specific right now. > > This is an important issue though. Now that Rails is a default choice for > so many teams, we're seeing more and more specialists needing to code on > projects who don't have a competency in Ruby. In fact, many of them are > already familiar with the plethora of choices in the Node ecosystem. For > them, using Sprockets only slows them down, and makes it harder to reuse > existing code. In fact, that's the very reason I looked to Rails as > inspiration when building Half Pipe: it generates an opinionated, default > Grunt setup, but makes it easy to change that to anything else it needs to > be (I have a project right now where I'm using Broccoli & ES6 modules > without requirejs, but still used Half Pipe to set it all up). > > For me, and many other developers I've worked with, using Sprockets (or > rails-assets) to abstract away the systems I already use in other projects > is more of a curse than a blessing. I know the systems, so I'd rather just > use them. > > At the end of the day, the question of "should Half Pipe replace > Sprockets" is not the one we should be asking. The right question is "how > do we make it easier for *anything* to replace Sprockets". > > Would the core team consider approaches that make the asset pipeline more > configurable? > > On Wednesday, June 11, 2014 7:48:00 AM UTC-4, Rodrigo Rosenfeld Rosas > wrote: > >> On 11-06-2014 03:01, Frank Tellefsen wrote: >> >> 2014-06-10 0:36 GMT+02:00 Ryan Bigg <[email protected]>: >> >> >> > Why would the community do that? What are the benefits? >> Why is Sprockets bad? >> ... >> - Live reload in development mode >> >> >> I'm curious (mostly afraid of, actually) about what this mean. Are you >> talking about automatically refreshing the page when the assets change? If >> so, I hope this is not enabled by default. I wouldn't use something like >> this while developing my application. >> >> ... >> > While I can see how Sprockets is not a good enough solution, I don't >> think that forcing users to convert their libraries in a RequireJS module >> is a good thing. >> >> I'm not a big fan of this either, but what are the alternatives? >> >> >> Well, I was never really very fond of RequireJS and haven't used it yet >> as I much prefer the approach taken by the Rails Asset Pipeline/Sprockets >> (this and automatic code reloading are the main reasons I prefer Rails over >> other alternatives). I think Sprockets directives a much better alternative >> to overcome the lack of a require/import statement in JS. RequireJS (and >> similar approaches) seems like an unnecessary complication from my point of >> view. >> >> I haven't spent any fair amount of time thinking about alternatives, but >> I'm pretty sure a better solution than using AMD exists until we target ES6. >> >> > I'd love to see some solid integrated JS dependency management tool >> to play well with Rails but I'm not sure if this is gonna happen any time >> soon. >> >> It's already here, and it's staring you right in the face. >> >> >> I must be blind then as I can't see it ;) >> >> -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/rubyonrails-core. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
