Introduce Webpacker and component approach #520
Conversation
DanilAgafonov
changed the title
| source "https://rails-assets.org" do | ||
| gem "rails-assets-jquery-ujs" | ||
| gem "rails-assets-jquery2" | ||
| end |
There was a problem hiding this comment.
Does this changes means that Assets Pipeline will be removed completely and replaced with Webpacker?
There was a problem hiding this comment.
Yup. Do you have concerns about it?
There was a problem hiding this comment.
Yes, I have. It could be more easy to understand if you suggest to add something new and leave all present things here and enable users to continue use technologies they know and technologies they have experience with. Assets Pipeline with all things we use everyday, like Coffee, like rails helpers etc IS compatible with Webpacker, they can be present in one project and work together. If you goal is - moving to new ES6 technology stack, why we MUST drop all previous experience? We did no have a choice? In case rails-base was regular open source project this will be good time to fork at because it will be non-useful for 50% of projects and 75% of developers. As I know almost all projects we start DO NOT require all this complex things, but now, after that change, every project will require react-developer right from start OR require BE developer to program with React / Node. More complex deployment, many new configs for ES6 transpiling, Nodejs, problem's with JQuery (that actually do the job for us, right, except religion questions)... So, really, it's more easy to fork this and drop 50% of things to get really "rails skeleton" lightweight and pre-configured for any type of projects.
There was a problem hiding this comment.
It makes sense. I think we need to get together BE and FE devs and discuss this case in office.
There was a problem hiding this comment.
@vladimirbazhanov https://evilmartians.com/chronicles/evil-front-part-1 what do you think about this?
I guess in the future projects it is better to start with modern technologies and frameworks.
Being a fresh Rails full-stack developer out in the wild is a confusing endeavor nowadays. A “classic Rails” way to handle front-end with Asset Pipeline, Sprockets, CoffeeScript, and Sass looks outdated in 2017. A lot of choices made back in the times of Rails 3.1 do not live up to modern expectations. Sticking with the “old way” means passing on everything that happened in the front-end community over the past half decade: the rise of npm as a JavaScript package manager to rule them all, the emergence of ES6 as a go-to JS syntax, the winning streak of transpilers and build tools, the ever-growing embrace of PostCSS as an alternative to CSS pre-processors. Not to mention the astounding success of front-end frameworks like React and Vue that change the very way we think about front-end code: components instead of “pages”.
|
@DanilAgafonov lets maybe find some time and finish this work? Let me know how I can help here |
|
I'' close this PR shortly because we already applied almost all features from it into master. Thanks for great work here! |
Summary
In this PR we replace Asset Pipeline with Webpacker.
app/views/application/_footer.html.slimalready adapted) (Pagination need to be updated too)app/assets/stylesheets/components/. Maybe this styles are not needed now. If they needed, move it as style for specific component.Test plan
List of steps to manually test introduced functionality:
Review notes
While reviewing pull-request (especially when it's your pull-request),
please make sure that:
.env.exampleand added to HerokuDeploy notes
Notes regarding deployment the contained body of work.
These should note any db migrations, ENV variables, services, etc.