Comments (13)
@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:
- 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 taskwebpacker
: 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.
Good stuff! Some feedback:
- 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.)
- 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.
@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.
@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.
@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.
@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.
I don't think folks are talking about removing sprockets, just making sure that webpacker doesn't depend on its presence.
from webpacker.
from webpacker.
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.
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.
@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.
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.
@justin808 Should we close this one now? #153 is merged
from webpacker.
Related Issues (20)
- Webpacker 6 Disable Babel HOT 1
- Webpacker compilation takes more than 1.5 hours HOT 11
- How do I allow a package in node_modules to be processed by babel? HOT 1
- Remove addition of node_modules to Rails.application.config.assets.paths HOT 1
- V6 Status HOT 3
- Raise an error when javascript_pack_tag or stylesheet_pack_tag are called more than once HOT 1
- Regular Expression Denial of Service in postcss HOT 2
- Intermittent Webpacker.dev_server.running? behavior HOT 2
- Host for assets from a webpacker configuration using custom domains not being resolved HOT 2
- Cherry-pick "Nothing to do" logging update onto `5.x` HOT 1
- Rails 6 WebPacker is not calling JQuery inside views HOT 1
- Security Vulnerability in [email protected] HOT 2
- currently no loaders are configured to process this file HOT 1
- Incompatibility with Ruby 3.2.0 HOT 2
- Confusing gem description on RubyGems HOT 1
- Npm package for 5.4.4 was not released HOT 2
- class variable @@local_levels of ActiveSupport::Logger is overtaken by Logger HOT 2
- Trying to deploy but assets assets:precompile fail
- Security Vulnerability for postcss
- Postcss Security Vulnerability
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from webpacker.