GithubHelp home page GithubHelp logo

Comments (13)

rupurt avatar rupurt commented on May 5, 2024 4

@justin808 this is a great summary and I'd love to help out. The killer part as you mentioned, is that it can be used for legacy Rails projects!

I've just got a few questions:

  1. The manifest strategy & standard Rails helpers can be used by any of the build systems (rollup, browserify, gulp etc...). How would you feel about splitting this into 2 projects? e.g.
  • frontend_on_rails (or some cooler name...): This manages the location of the manifest file, calling the precompile task
  • webpacker: This manages webpack config, dev server, manifest plugin setup

3 & 4) By using the manifest files you shouldn't need to create new helpers. You should be able to use all of the existing ones.

from webpacker.

dleavitt avatar dleavitt commented on May 5, 2024 2

Good stuff! Some feedback:

  1. Provide view helpers for exposing webpack created JavaScript and stylesheet tag helpers that are the webpack equivalents of

We shouldn't need new helpers once we're using a manifest everywhere. Webpacker can patch the built-in Rails helpers to be webpacker-aware.

This is what compute_asset_path is for. Webpacker should patch this and then fallback to sprockets if the asset isn't found (or vice-versa.) This is exactly how sprockets-rails does it right now - looks in the sprockets manifest and if not found falls back to the the default Rails behavior (look in the public folder.)

  1. Via a new file, /config/webpack.rb

This shouldn't be needed. Sensible defaults should be set, and they can be overridden in application.rb or one of the environment config files.

from webpacker.

rupurt avatar rupurt commented on May 5, 2024 1

@justin808 I deal with that by using a suffix for webpack generated files i.e. my-js-bundle. I then add a regex check for -bundle in the asset host configuration.

# application.rb
# ...

if ENV["ASSET_HOST"].present?
   config.action_controller.asset_host = proc { |source, _request|
      if Rails.env.development?
         if source =~ /-bundle/
            ENV["ASSET_HOST"]
         # else
            # return nil and use the server host
         end
      else
         ENV["ASSET_HOST"]
      end
   end
end

# ...

from webpacker.

rupurt avatar rupurt commented on May 5, 2024 1

@dhh good to know.

I wrapped up my ideas on the integration into a separate gem webpack_on_rails. It contains an install generator which creates the Webpack config files in a similar way to webpacker as well as configuring the location of the manifest file and disabling asset debug in development mode. This allows the standard view helpers javascript_include_tag, stylesheet_link_tag, etc... to be used instead of the new javascript_pack_tag.

e.g.

<% # app/views/layouts/application.html.erb %>
<!DOCTYPE html>
<html lang="en">
  <head>
    <%= stylesheet_link_tag "webpack-application", media: :all %>
  </head>
  <body>
    <%= yield %>

    <%= javascript_include_tag "webpack-application" %>
  </body>
</html>

As I mentioned in the previous comment, the core of this idea can be used to integrate any build system (grunt, rollup, browserify...). The manifest location & disabling asset debug in development are the common pieces, and it would be up to the build system to write a compatible manifest file.

If we improved sprockets slightly, and reloaded the manifest file when it changes in development, we could also enable asset fingerprints for the development workflow.

from webpacker.

justin808 avatar justin808 commented on May 5, 2024

@dleavitt could a /config/webpack.rb by the webpack equivalent of assets.rb? I'd like to see the default configs listed and commented out, so it's clear what can be overridden.

Regarding the built-in rails helpers...what if somebody wants to turn off sprockets? Maybe if put the helpers in a separate very lean, webpack 2.2+ focused gem, then Sprockets can refer to that gem to patch the existing helpers? The unusual thing about Webpack integration is that we want to enable a hot reloading server for the assets sometimes, but not always (per ENV value), for development mode.

Maybe we can patch the javascript_include_tag and stylesheet_link_tag so that they would first pick a webpack source? Another issue is whether the options that make sense for these helper methods would also apply to webpack files.

If the options for webpack bundle files should be different, then, IMHO, it would be more confusing to overload the old helper names, and new helper names should be used.

I created a label for open issues on React on Rails pertaining to Webpacker and Sprockets. @rupurt has done some work here in issue #696. I recently merged PR 671: Ability to work without Sprockets, which brings up another issue in that there is no assets:precompile if Sprockets is not used. I'm going to update the top description so that it reflects the ability to work without sprockets as a requirement.

from webpacker.

rupurt avatar rupurt commented on May 5, 2024

@justin808 I'm interested to hear more about the use case of completely removing sprockets. We still use sprockets to inline styles for our mailers and then we also use it for the manifest file mapping when we use the helpers.

At this point I don't think we should try to remove sprockets but rather leverage what it already gives us. I'd love to know more about how an app works with it removed though i.e. how do you reference assets?

Have you had a chance to look at configuring the asset host in development for the dev server? You can guard it with an environment conditional and you don't need to change anything to do with the helpers. https://github.com/rupurt/webpack-sprockets-rails-manifest-plugin#hot-module-replacement

from webpacker.

dleavitt avatar dleavitt commented on May 5, 2024

I don't think folks are talking about removing sprockets, just making sure that webpacker doesn't depend on its presence.

from webpacker.

dleavitt avatar dleavitt commented on May 5, 2024

from webpacker.

justin808 avatar justin808 commented on May 5, 2024

@rupurt

Have you had a chance to look at configuring the asset host in development for the dev server? You can guard it with an environment conditional and you don't need to change anything to do with the helpers. https://github.com/rupurt/webpack-sprockets-rails-manifest-plugin#hot-module-replacement

Very cool! It just won't work if you need to be selective about which assets in case you have some old sprockets and some new webpack ones.

from webpacker.

dhh avatar dhh commented on May 5, 2024

Just to set realistic expectations here: Rails 5.1 is essentially a wrap. We're not going to add any additional provisions for non-JS webpack helpers in that release. The next stop will be either Rails 5.2 or Rails 6.0. So we'll have a good amount of time (6-9 months, at least) to sort out how it should all feel.

I'm not big on overwriting the existing helpers in any case, though. We should provide a smooth transition path from asset pipeline to webpack and allow people to combine them both in a single app. That's the magic behind Webpacker and the javascript pack tag. They can just coexist. So let's continue down along that path.

We've discussed the HELLOs in other tickets, btw. For now they stay to provide the bare minimum bootstrapping. Then other gems and efforts can go above and beyond that.

from webpacker.

dhh avatar dhh commented on May 5, 2024

@rupurt I think that's totally fine to keep as a separate project. I don't think Rails out-of-the-box needs to support anything beyond the asset pipeline and webpack, but it's good for us to make it easy to for others to provide integration with other build systems 👍

from webpacker.

justin808 avatar justin808 commented on May 5, 2024

Just to set realistic expectations here: Rails 5.1 is essentially a wrap. We're not going to add any additional provisions for non-JS webpack helpers in that release. The next stop will be either Rails 5.2 or Rails 6.0. So we'll have a good amount of time (6-9 months, at least) to sort out how it should all feel.

In the early days of React on Rails, we had our generators try to set up CSS modules, linting, hot reloading, etc. This added a TON of extra complexity. There's no reason that the current asset pipeline can't continue to handle non-JS assets as it has always done. That being said, if you turn hot reloading on for JS, the CSS won't hot reload. It might be worth considering if hot reloading (vs. hitting CMD-R) is really worth the maintenance.

I'm not big on overwriting the existing helpers in any case, though. We should provide a smooth transition path from asset pipeline to webpack and allow people to combine them both in a single app. That's the magic behind Webpacker and the javascript pack tag. They can just coexist. So let's continue down along that path.

💯 agree on keeping the helpers separate!

from webpacker.

gauravtiwari avatar gauravtiwari commented on May 5, 2024

@justin808 Should we close this one now? #153 is merged

from webpacker.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.