Make Webpacker the default JavaScript compiler for Rails 6 #33079

Open
wants to merge 27 commits into
from

Conversation

Projects
None yet
10 participants
@dhh
Member

dhh commented Jun 7, 2018

This is a work-in-progress branch for promoting Webpacker to the default JavaScript compiler for Rails 6.0. There's a lot of work to be done on both the generators, documentation, and more. So don't expect this to be fully functional in a jiffy.

@dhh dhh added this to the 6.0.0 milestone Jun 7, 2018

@simi

This comment has been minimized.

Show comment
Hide comment
@simi

simi Jun 7, 2018

Contributor

I think it is still valid to check no wild jQuery suddenly appears. :trollface:

Contributor

simi commented on 55d5a95 Jun 7, 2018

I think it is still valid to check no wild jQuery suddenly appears. :trollface:

- else
- GemfileEntry.new "mini_racer", nil, comment, { platforms: :ruby }, true
+ [ GemfileEntry.version("turbolinks", "~> 5",
+ "Turbolinks makes navigating your web application faster. Read more: https://github.com/turbolinks/turbolinks") ]

This comment has been minimized.

@yhirano55

yhirano55 Jun 7, 2018

Contributor

Turbolinks is added on package.json, so it looks unnecessary to add turbolinks to Gemfile.

@yhirano55

yhirano55 Jun 7, 2018

Contributor

Turbolinks is added on package.json, so it looks unnecessary to add turbolinks to Gemfile.

This comment has been minimized.

@dhh

This comment has been minimized.

Show comment
Hide comment
@dhh

dhh Jun 7, 2018

Member
Member

dhh commented Jun 7, 2018

@dhh

This comment has been minimized.

Show comment
Hide comment
@dhh

dhh Jun 19, 2018

Member
Member

dhh commented Jun 19, 2018

@rainerborene

This comment has been minimized.

Show comment
Hide comment
@rainerborene

rainerborene Jun 25, 2018

@dhh that means that sprockets will no longer be a dependency on Rails?

@dhh that means that sprockets will no longer be a dependency on Rails?

@dhh

This comment has been minimized.

Show comment
Hide comment
@dhh

dhh Jun 25, 2018

Member
Member

dhh commented Jun 25, 2018

dhh added some commits Jun 25, 2018

Drop the JS assets generator
It was barely helpful as it was. It’s no longer helpful in a Webpacked
world. Sayonara!
Simpler import style
Which match the other imports.

@mklabs mklabs referenced this pull request in yeoman/yo Jun 25, 2018

Closed

Credits on original ideas #585

@sorrycc sorrycc referenced this pull request in sorrycc/zaobao Jun 26, 2018

Open

早报 @ 2018.6.26 #52

@dwightwatson

This comment has been minimized.

Show comment
Hide comment
@dwightwatson

dwightwatson Jun 26, 2018

Contributor

Out of curiousity, what is the argument to continue using Sprockets for CSS/static assets when Webpacker supports them by default out of the box?

Contributor

dwightwatson commented Jun 26, 2018

Out of curiousity, what is the argument to continue using Sprockets for CSS/static assets when Webpacker supports them by default out of the box?

@dhh

This comment has been minimized.

Show comment
Hide comment
@dhh

dhh Jun 26, 2018

Member
Member

dhh commented Jun 26, 2018

@Marcohj

This comment has been minimized.

Show comment
Hide comment
@Marcohj

Marcohj Jun 26, 2018

Sprockets = SASS
Webpack = SASS/LESS/PostCss and the future

Rails should be ready to embrace the future ❤️

Marcohj commented Jun 26, 2018

Sprockets = SASS
Webpack = SASS/LESS/PostCss and the future

Rails should be ready to embrace the future ❤️

@adrianthedev

This comment has been minimized.

Show comment
Hide comment
@adrianthedev

adrianthedev Jun 26, 2018

My javascripts folder already has the images, js, packs, stylesheets folders inside. Would be nice to use the old assets folder instead of the current javascripts to hold all assets.

adrianthedev commented Jun 26, 2018

My javascripts folder already has the images, js, packs, stylesheets folders inside. Would be nice to use the old assets folder instead of the current javascripts to hold all assets.

@rainerborene

This comment has been minimized.

Show comment
Hide comment
@rainerborene

rainerborene Jun 27, 2018

No, Sprockets is still to be used for SCSS (and other CSS processors) as well as copying all other static assets.

@dhh I see your point. But it's inevitable that these JavaScript packages will make use of their own internal styling (like React or something). So, you'll end up with styles in two separate places and from different "compilers". That could become a mess, don't you think?

No, Sprockets is still to be used for SCSS (and other CSS processors) as well as copying all other static assets.

@dhh I see your point. But it's inevitable that these JavaScript packages will make use of their own internal styling (like React or something). So, you'll end up with styles in two separate places and from different "compilers". That could become a mess, don't you think?

@dhh

This comment has been minimized.

Show comment
Hide comment
@dhh

dhh Jun 27, 2018

Member
Member

dhh commented Jun 27, 2018

@frodsan

This comment has been minimized.

Show comment
Hide comment
@frodsan

frodsan Jul 1, 2018

Contributor

@adrianthedev you can change the default path in .webpacker.yml:

default: &default
- source_path: app/javascript
+ source_path: app/assets
Contributor

frodsan commented Jul 1, 2018

@adrianthedev you can change the default path in .webpacker.yml:

default: &default
- source_path: app/javascript
+ source_path: app/assets
@adrianthedev

This comment has been minimized.

Show comment
Hide comment
@adrianthedev

adrianthedev Jul 1, 2018

For sure I can do that @frodsan. But by doing it that it would change the default "rails" way.

This is the turning point when we can have that default path in assets and all generators and other packages point to that.
Again, making it the rails way (and the consistent way) of keeping everything (js, images, css, etc.) in the assets folder and giving the developer the choice of using Webpack or sprockets for his CSS.
It seems as the perfect setup.

For sure I can do that @frodsan. But by doing it that it would change the default "rails" way.

This is the turning point when we can have that default path in assets and all generators and other packages point to that.
Again, making it the rails way (and the consistent way) of keeping everything (js, images, css, etc.) in the assets folder and giving the developer the choice of using Webpack or sprockets for his CSS.
It seems as the perfect setup.

@kaspth

This comment has been minimized.

Show comment
Hide comment
@kaspth

kaspth Jul 5, 2018

Member

Should we somehow honor config.assets calls such that gems that bundle assets don't need to do this: https://github.com/turbolinks/turbolinks-rails/pull/18/files#diff-9da50910637da91c22aff050425a9fabR17

cc @guilleiguaran

Member

kaspth commented Jul 5, 2018

Should we somehow honor config.assets calls such that gems that bundle assets don't need to do this: https://github.com/turbolinks/turbolinks-rails/pull/18/files#diff-9da50910637da91c22aff050425a9fabR17

cc @guilleiguaran

@jcoyne jcoyne referenced this pull request in projectblacklight/blacklight Jul 13, 2018

Open

app/views/layouts/blacklight/base.html.erb assumes sprockets #1926

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment