Add option to have css/images managed through webpack

[dleavitt]

I think it would be useful to have an additional generator that supports all FE assets being managed through Webpack. I'd love to gauge interest and get feedback before I start on a PR.

Background:

As far as I know there, are two basic options for managing images/css/etc in a webpack + rails app.

Option 1: Manage Javascript through Webpack and everything else through Sprockets.
This is only option currently supported out of the box.

• Advantages: Easy to set up, legacy app friendly, easy to reference images, etc. from erb.
• Disadvantages: Still clunky (as noted in README). Still no good system for managing vendor CSS dependencies. Doesn't make CSS a first class citizen of the front end app, which means no loading css from node_modules and no support for modular CSS approaches (used by Vue, Material Design, etc.)

Option 2: Manage all assets through Webpack, remove Sprockets.

This involves adding some loaders to webpacker (probably file-loader and sass/css/style loaders) as well as a manifest generator that Rails can use to get properly fingerprinted paths in erb and such.

• Advantages:
  • Allows easy use of Vue, CSS modules, and lots of other things that frontend developers dig.
  • More broadly, this is the way most frontend apps are structured nowadays. Tutorials and example apps will work out-of-the-box with Rails.
  • Removes Sprockets entirely for apps that don't need it, no more need for two separate asset pipelines. No need to mess with bower or https://rails-assets.org.
• Fixes a bunch of things in one stroke, eg Expose bundles to Sprockets #91, Add stylesheet_pack_tag method #79, etc.
• Disadvantages:
  • Ultimately need to modify or duplicate all existing asset helpers to work with the webpack-generated manifest.
  • Additional webpack complexity around manifest generation and CSS extraction and other things we want production-ready defaults for. Potentially more moving pieces on the webpack side.

I'd be interested in creating a generator to support option 2 (either as an alternative to webpacker:install or as an additional generator that can be run after it.) Option 1 would be left as the default.

I think this feature could also provide the first step on a gradual path to moving Sprockets out of
core. I think the technical risk of relying on Webpack (or another successor library) is less than than the risk of relying on Sprockets. Sprockets is a very complex library (and I suspect a maintenance pain point.) It was a major step forward for its time but is showing its age; most of its functionality is better provided by Webpack, which will soon be part of Rails.

[dhh]

Happy to see a PR explore option #2 👍

…

On Thu, Feb 23, 2017 at 8:30 PM, Daniel Leavitt ***@***.***> wrote: I think it would be useful to have an additional generator that supports *all* FE assets being managed through Webpack. I'd love to gauge interest and get feedback before I start on a PR. Background: As far as I know there, are two basic options for managing images/css/etc in a webpack + rails app. *Option 1:* Manage Javascript through Webpack and everything else through Sprockets. This is only option currently supported out of the box. - *Advantages:* Easy to set up, legacy app friendly, easy to reference images, etc. from erb. - *Disadvantages:* Still clunky (as noted in README). Still no good system for managing vendor CSS dependencies. Doesn't make CSS a first class citizen of the front end app, which means no loading css from node_modules and no support for modular CSS approaches (used by Vue, Material Design, etc.) *Option 2:* Manage *all* assets through Webpack, remove Sprockets. This involves adding some loaders to webpacker (probably file-loader and sass/css/style loaders) as well as a manifest generator that Rails can use to get properly fingerprinted paths in erb and such. - *Advantages:* - Allows easy use of Vue, CSS modules, and lots of other things that frontend developers dig. - More broadly, this is the way most frontend apps are structured nowadays. Tutorials and example apps will work out-of-the-box with Rails. - Removes Sprockets entirely for apps that don't need it, no more need for two separate asset pipelines. No need to mess with bower or https://rails-assets.org. - Fixes a bunch of things in one stroke, eg #91 <#91>, #79 <#79>, etc. - *Disadvantages:* - Ultimately need to modify or duplicate all existing asset helpers to work with the webpack-generated manifest. - Additional webpack complexity around manifest generation and CSS extraction and other things we want production-ready defaults for. Potentially more moving pieces on the webpack side. I'd be interested in creating a generator to support option 2 (either as an alternative to webpacker:install or as an additional generator that can be run after it.) Option 1 would be left as the default. I think this feature could also provide the first step on a gradual path to moving Sprockets out of core. I think the technical risk of relying on Webpack (or another successor library) is less than than the risk of relying on Sprockets. Sprockets is a very complex library (and I suspect a maintenance pain point.) It was a major step forward for its time but is showing its age; most of its functionality is better provided by Webpack, which will soon be part of Rails. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#109>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAKtQh2y4TBAwTXj89f05iU8lWtKSAZks5rfd5KgaJpZM4MKZTk> .

[dleavitt]

Great, I'll get started!

[dhh]

❤️❤️❤️

…

On Thu, Feb 23, 2017 at 8:46 PM, Daniel Leavitt ***@***.***> wrote: Great, I'll get started! — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#109 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAKtVg8MW81p1pt1JLgLKuxzksJCbOiks5rfeIQgaJpZM4MKZTk> .

[gauravtiwari]

@dleavitt @dhh Made an example app that uses webpacker + some additional changes that could be incorporated into Webpacker to make it work with static assets like css, images and fonts for app like javascripts.

Javascript app code

https://github.com/gauravtiwari/webpacker-example-app/tree/master/app/javascript/counter

Some minor patches to source lookup class

https://github.com/gauravtiwari/webpacker-example-app/blob/master/app/lib/webpack/source.rb

Now using webpack manifest plugin, which maps all assets by default like this in production,

{
  "clock.png": "/packs/clock-fc31531de5cc3518c7c658d5b83faa72.png",
  "counter.css": "/packs/counter-c38deda30895059837cf.css",
  "counter.js": "/packs/counter-300631c4f0e0f9c865bc.js",
  "lacuna-webfont.eot": "/packs/lacuna-webfont-54c0d12c6ab265792f0d8cfd81e481e4.eot",
  "lacuna-webfont.svg": "/packs/lacuna-webfont-58e9f0ae5f3dec1ea00ef1a1ad099e8c.svg",
  "lacuna-webfont.ttf": "/packs/lacuna-webfont-1acb63487c4a72f7fd2e545d2e0090e2.ttf",
  "lacuna-webfont.woff": "/packs/lacuna-webfont-0eb6add367ef5fc69c4569894525bd52.woff"
}

and in development,

{
  "clock.png": "/packs/clock.png",
  "counter.css": "/packs/counter.css",
  "counter.css.map": "/packs/counter.css.map",
  "counter.js": "/packs/counter.js",
  "lacuna-webfont.eot": "/packs/lacuna-webfont.eot",
  "lacuna-webfont.svg": "/packs/lacuna-webfont.svg",
  "lacuna-webfont.ttf": "/packs/lacuna-webfont.ttf",
  "lacuna-webfont.woff": "/packs/lacuna-webfont.woff"
}

it solves problem around linking multiple asset types with same name as we are using proper extensions in this manifest.

Asset helper

An asset helper that generates appropriate HTML tags based on a given asset - module.js.
https://github.com/gauravtiwari/webpacker-example-app/blob/master/app/helpers/application_helper.rb

View integration

https://github.com/gauravtiwari/webpacker-example-app/blob/master/app/views/pages/index.html.erb

Webpack configs

Updated webpack configs to incorporate fonts, styles and images
https://github.com/gauravtiwari/webpacker-example-app/blob/master/config/webpack/shared.js
https://github.com/gauravtiwari/webpacker-example-app/blob/master/config/webpack/production.js

Demo

https://webpacker-example-app.herokuapp.com/

Thought it would be good idea to visually look at this in action in a Rails app and then make a PR with the required changes.

---

Also, on another note it seems we should remove react, angular and vue integrations out of this Gem. Perhaps, it's best we leave those integrations to community using a separate gems that depends on Webpacker because there are just tons of frameworks and they all work differently. Webpacker can be used to integrate webpack and yarn into a Rails app, instead of sprockets (in future). Will create an issue to discuss this further.

[renchap]

This looks like a nice start!

I am not fond of having non-JS code in app/javascript. If the goal is to have assets handled either by Sprockets or Webpacker, could we have Webpack process app/assets/* (minus javascript) and maybe keep the stylesheet_link_tag helper, but now loading from Webpack? I dont know if this is doable, but it might ease the transition to Webpacker.

@dhh, do you have an opinion on assets should be handled "long-term"? Should it be only Webpacker or Sprockets (for non-JS assets), or have support for Sprockets+Webpacker at the same time?

As for your last comment, I agree. For React, we could easily move the webpacker:react task into https://github.com/renchap/webpacker-react. I think it makes much more sense to avoid cluttering the Webpacker gem with many libraries. If the Rails team prefer to have "official" integrations, we could move all these JS framework adapters into the Rails GH team too.

[gauravtiwari]

@renchap Yeah, I agree. This is just to get an overview so, we can look at the options. I moved the static assets to app/assets folder, no code changes required except updating the path of the linked assets. Check this out - https://github.com/gauravtiwari/webpacker-example-app/tree/feature/use-assets-folder/app/assets
https://github.com/gauravtiwari/webpacker-example-app/tree/feature/use-assets-folder/app/javascript/counter

If we are moving to webpack eventually, one asset helper tag would be enough because we can use the webpack manifest file to lookup and map generated assets. I guess this will make server rendering easy too.

---

Yes, perhaps something like omniauth with it's many adapters.

[dleavitt]

Wow, that was fast! Nice work!

✋ 👈 that is a high five. High five!

I have some thoughts:

1. Using argv[0] to determine whether we're running the dev server seems like it could be fragile? Alternatives:

   • Have the dev-server binstub use a separate webpack config that wraps the one for the current environment.
   • Have the dev-server binstub pass an ENV var or argument that tells the webpack config whether to set a publicPath.
   • Just put the http://localhost:8080/ in the webpack development config (commented out by default) and let people uncomment in manually, as they already do in development.rb.
   • Could we somehow get config.x.webpacker[:dev_server_host] from Rails? We're always going to want to match this value.

   I'd also suggest that this logic should be in development.js rather than shared.js by default.

2. Rather than adding pack_tag that forwards to the Rails helpers, it should be pretty easy to make all the Rails helpers work with Webpack. I believe this is downstream of all asset helpers and that all options will be forwarded to it. Override it to check for a pack: true option or similar and let Webpacker handle if found. So like image_tag 'hoglord.png', pack: true would just work. I think it also makes sense to leave the current javascript_pack_tag in place for now as well, since it's simple and people are using it.

3. Right now it looks like the structure of app/javascript is being flattened when compiled. This means that no two assets anywhere in your tree can have the same name. You can kinda solve this by prepending [path] to your file-loader's name field. This doesn't (I don't think) solve the problem for on-demand loading or extract text loader or anything else. I think the basic problem here is that webpacker is built in a way that assumes only files in javascript/packs will end up in public/packs, which isn't going to be the case. I'm going to open a separate ticket for this I think.

4. Could the way the file-loader rules are implemented be more DRY and also more transparent? Can you export a list of static file extensions from shared.js and use it in production.js? This is always something that's bugged me about webpack and file-loader in particular.

5. Kinda related to 3, does it make sense to use the manifest always, rather than just when things are digested? Are there situations where assets might end up at different paths depending on the environment / build strategy?

Anyway, this basically looks great and I think you or somebody should prepare some PRs. I'm thinking:

• PR 1: Switch to using manifest.json, add pack_tag (or the pack: true thing if it's easy), make sure javascript_pack_tag still works. Use publicPath.

• PR 2: Add webpacker:install:something, which includes file-loader and the associated webpack config updates and addresses points 1, 2, 3 and 4 above.

@renchap remember that this is intended (for now) to be a non-default alternative to using sprockets + webpack. People who are using webpack to manage their CSS and images are generally going to want them in the same paths as their Javascript.^{citation needed} A very popular way to do it nowadays is to organize your app by components, and have all JS, assets, views, and CSS for a component live together in the same directory (or same file in Vue's case.)

That said it's at some point worth discussing a number of larger issues around this, including whether javascript is the right name for the folder, what the various rails generators should do, etc.

[justin808]

There's no reason to keep CSS separate from JavaScript with CSS modules.

Here is an example: https://github.com/css-modules/webpack-demo/blob/master/src/components/1-ScopedSelectors/ScopedSelectors.js

[gauravtiwari]

@dleavitt ✋ Okay so you wrote a ton of things 😄 so, let me read it and then we can work on it together. I saw @justin808 also opened an issue (#130) around directory organisation. This is good thing that everyone is coming together and contributing so, I suggest lets use this opportunity to discuss around these issues and then work on it through PR's otherwise we might have to face a lot of PR conflicts and duplicates.

[justin808]

@gauravtiwari I took a look at gauravtiwari/webpacker-example-app@c617c1c. To me, this clearly shows that we should keep the old Rails assets that are loaded from the older Rails asset helpers into ERB files totally separate.

I think it's critical that non-JS assets can be loaded the webpack way, which is to use require or import with minimal path manipulation. CSS modules should be completely supported as they are awesome. I'm happy to show any of you the source code on a very large, production project that makes extensive use of mixing CSS and image assets with the JS files. Keeping styling and images local to the components that uses them helps greatly with avoiding huge amounts of asset clutter.

[justin808]

@dleavitt Regarding

Rather than adding pack_tag that forwards to the Rails helpers, it should be pretty easy to make all the Rails helpers work with Webpack. I believe this is downstream of all asset helpers and that all options will be forwarded to it. Override it to check for a pack: true option or similar and let Webpacker handle if found. So like image_tag 'hoglord.png', pack: true would just work. I think it also makes sense to leave the current javascript_pack_tag in place for now as well, since it's simple and people are using it.

Maybe we could have a global default that pack: true, so that you'd only specify pack: false if you needed it.

OTOH, I like what @gauravtiwari did by creating just one helper asset_pack_tag: https://github.com/gauravtiwari/webpacker-example-app/blob/b591c65ea94fd31fe309a1753ce5ab44342c7407/app/helpers/application_helper.rb#L5

I would probably just go with @gauravtiwari and replace the "javascript_pack_tag" with the "asset_pack_tag".

[gauravtiwari]

@dleavitt Some notes for you on the points you commented earlier :),

Point 1

Yes, it's seems reasonable to use the options you suggested and don't think it's complicated. All the options could be passed via the binstubs provided. We can set env variables during runtime and then the config will have access to it.

On other note, about commenting the dev server config, I feel perhaps we shouldn't comment anything out that we feel is the standard practice for that environment, to give the developers the best experience and integrated setup.

Point 2

As for this one, I feel it's best we don't mess up with asset pipeline helper at this point and rather spend our time to create something that works with Webpacker. Probably, this will confuse folks so, I guess it's best if we develop a set of tools around this Gem that works really well and integrated with Rails framework, not particularly asset pipeline or sprockets. Those systems are already well evolved as of now and works. Did you checked this helper tag? https://github.com/gauravtiwari/webpacker-example-app/blob/master/app/helpers/application_helper.rb#L4

How does it feels like? (Given we ignore asset pipeline for now completely)

Point 3

I agree. As @justin808 pointed out couple of ideas in this (#130) comment regarding directory structure. Perhaps, we can take all that together and discuss this in that thread, however this looks nice though.

Point 4

Absolutely, that was basically a quick setup to see how things might work. Although, as you mentioned there are a couple of gotchas that will come in the way. We will see.

Point 5

Yes, that's what manifest plugin does, we have digests.json generated all the time, whenever the webpack server or watcher is re-run. See this comment, #109 (comment)

Summary

So, overall it feels that for this particularly issue we need following, considering we don't bother about asset pipeline for now and assuming, this setup is purely for developing client side app's in javascript and not sprinkles,

• Pass required env vars into configs (DEV_SERVER_RUNNING, DEV_SERVER HOST etc.).
• Use and configure file loader and such to manage static assets using Webpack.
• DRY up the configurations around file loader.
• Move config to it's place - like something for development env should not be in shared.js
• Preserve directory structure for static assets after build for clarity.
• Have a digests.json that keep tracks of all assets and is generated and updated live, this is already in place https://github.com/gauravtiwari/webpacker-example-app/blob/master/config/webpack/shared.js#L90
• Create a helper tag that links Webpack assets in ERB. Perhaps, just use this for now https://github.com/gauravtiwari/webpacker-example-app/blob/master/app/helpers/application_helper.rb#L4

Obviously, we can just use CSS modules as @justin808 suggested, however I am not sure if this works for everyone. Perhaps, we can provide both options.

• Refactor source and digests ruby class so, the bundle lookup is more transparent (consider cases like server rendering etc.). This is how it looks now with new manifest, https://github.com/gauravtiwari/webpacker-example-app/blob/master/app/lib/webpack/source.rb#L8

@renchap and @justin808 can share some thoughts on server rendering and if any special setup is required for third party integration that we should have in this Gem ? I guess having a manifest of all assets will make this very transparent as we can lookup bundles and use it during server rendering.

For other issues like folder names, lets discuss and track them in separate threads.

[dleavitt]

@gauravtiwari awesome, thanks so much for the thoughtful reply!

commenting the dev server config

I just suggested this for consistency with development.rb (where dev_server_host is commented out by default.) If we can do it with an ENV var then it doesn't matter.

feel it's best we don't mess up with asset pipeline helper

I'm actually just suggesting we do what sprockets does; override compute_asset_path to make it aware of webpacker. That said I think your approach is much better as a first pass; I'll save my suggestion for a subsequent PR.

As @justin808 pointed out couple of ideas in this (#130) comment regarding directory structure

I think his ideas are interesting (and probably based on a lot of experience.) However they're pretty radical, and I don't think they should be part of this PR for now. I was more concerned with the structure within public/packs (see #127) which I think might get us in trouble down the road. But let's avoid this issue until it's a blocker.

Yes, that's what manifest plugin does

Right, but the manifest is not actually used unless digesting is on. I suspect we'll eventually need to use it for non-digesting requests as well, but again, let's cross that bridge when we get to it.

Your checklist looks great to me! A few notes:

Use and configure file loader

I don't think we should have webpacker:install include file-loader by default for now. Let's just make sure it works and add instructions to the README for now?

Preserve directory structure for static assets after build for clarity

If we can get the rest of the stuff done without this it might be a good idea to do this as a separate PR. Naming things is always controversial 🙂

Create a helper tag that links Webpack assets in ERB

I like what you've got right now. Just make sure javascript_pack_tag still works ❤️

Obviously, we can just use CSS modules as @justin808

I think if we do this right it will make it easy to use CSS modules or any other setup folks might want to use. We can be agnostic about this.

server rendering

Again, I think this should be on the roadmap but maybe not addressed here. Baby steps 👶

[gauravtiwari]

@dleavitt Great 😄

Oh yes, sorry I meant in terms of directory and naming in general (since that's been discussed), not technically and I agree about preserving public/packs layout (in another PR). In regards to your file loader comment, do you think it's best we leave it to readme for now? Don't think it's a lot of changes.

So, I think once #111 is merged I can start making a PR on this and we can work together on that to finish up the feature.

TODO

• Pass required env vars into configs (DEV_SERVER_RUNNING, DEV_SERVER HOST etc.).
• Use and configure file loader and such to manage static assets using Webpack.
• Move config to it's place - like something for development env should not be in shared.js
• Have a digests.json that keep tracks of all assets and is generated and updated live, this is already in place https://github.com/gauravtiwari/webpacker-example-app/blob/master/config/webpack/shared.js#L90
• Create a helper tag that links Webpack assets in ERB. Perhaps, just use this for now https://github.com/gauravtiwari/webpacker-example-app/blob/master/app/helpers/application_helper.rb#L4
• Adjust source and digests ruby class so, it works with new setup.

Yep, that totally makes sense 👍

[dleavitt]

Awesome! yeah I think it's best not to add any new dependencies in this PR. We just want to make using file-loader possible, not actually install it.

[justin808]

share some thoughts on server rendering and if any special setup is required for third party integration that we should have in this Gem ? I guess having a manifest of all assets will make this very transparent as we can lookup bundles and use it during server rendering.

All we need is a controller helper to get a specific file compiled asset file by name, and at production time, the fingerprinted one is loaded.

Server rendering is running a JavaScript snippet with some library loaded (webpack bundle) and returning a string of HTML that is put on the rails view.

[swrobel]

👍 for grabbing dev_server_host from development.rb. Not very DRY having to run WEBPACK_DEV_SERVER_ADDR=http://packs.dev/ webpack-dev-server when the address is also set in development.rb

[justin808]

@swrobel @gauravtiwari FWIW, we've given up on the hot reloading for our biggest application and we are instead relying on the Webpack DLL to speed up build times. I tend to create different Procfiles to either run static asset creation or hot reloading. This stuff is changing all the time. Sometimes, hot reloading is working. Sometimes it's not.

[dhh]

A few quick thoughts:

• The default directory structure should continue to support and recommend app/assets for static assets like images, fonts, and css. Happy to also see a path where people can go with a component-based approach and put those things together, but that won't be the out-of-the-box recommendation. Just like we don't bundle controllers, views, and assets in general together from the server side.
• As mentioned in other PRs, Webpacker should continue to coexist with the asset pipeline. So that means using separate view helper tags. stylesheet_pack_tag etc.

Haven't had a chance to look at the code here yet, though. So that's just the preliminary thoughts.

Awesome to see this progress so quickly! Thanks to everyone working on it and chiming in. ❤️

[gauravtiwari]

Thanks to you too ❤️ I am working on this one along similar lines. Will make a PR once ready.

[dleavitt]

@dhh I think webpacker can use the same view helpers in a way that's sprockets-agnostic, right?

Currently if you have sprockets (but not Webpacker) and use a view helper, the following happens:

1. View Helper called
2. Eventually calls compute_asset_path
3. check sprockets manifest (serve file if found)
4. Default rails behavior (serve from public folder) if not

With the addition of webpacker we just add one more step:

1. View helper called
2. Eventually calls compute_asset_path
3. check sprockets manifest (serve file if found)
4. check webpack manifest (serve file if found)
5. Default rails behavior (serve from public folder) if not

This means we only have to patch compute_asset_path and lots of the view helpers magically work.

Let me know if I'm off-base here, but this seems like a much more elegant long-term solution. And I think it's pretty easy to implement. compute_asset_path is built to accommodate this specific use-case, right?

[sealocal]

... which means no loading css from node_modules and no support for modular CSS approaches (used by Vue, Material Design, etc.) ...

FWIW, as a user of webpacker, I would like a way to do exactly that - load css from node_modules. One of my node packages includes a default stylesheet. If I understand, the only way can utilize the CSS is to copy it to vendor/assets/stylesheets and reference it in my view layout or sprockets manifest. If I upgrade the package, I will need to remember to upgrade the stylesheet separately. I imagine the same could be said about images and fonts.

I saw this in the Rails 5.1.0beta1 release blog post:

Everything you depend on via Yarn is then made available to be required in the asset pipeline, just like vendored dependencies would have been.

"Everything" had me hoping that I could reference this node package's CSS, but I think this means only JS dependencies can be referenced in the asset pipeline.

[justin808]

@sealocal I've already started an effort to provide what you want in a gem complimentary to Webpacker, so that all the functionality of full webpack support for non-JavaScript is full supported, as it's done right now for React on Rails.

[gauravtiwari]

@sealocal Not sure if I understood correctly, but I think you can do that with import('module_name/dist/module.css') within your components (although as of now you need to manually add css and style loaders). Also, a separate vendor bundle can be created and used for both JS and CSS i.e. from node_modules and referenced in the view that loads all vendor code.

I am working on this so, hopefully will have PR soon for you to review. Is that what you meant?

[sealocal]

@justin808 Is there a name for this other complimentary gem? I will take a look when its published.

@gauravtiwari Basically, I want to add to my component a syntax I've seen elsewhere:

import css from 'file.css'

I'm not so familiar with Webpack - I'm heavily leaning on webpacker. css-loader and style-loader did the trick - thanks for the suggestion!

It seems that loading assets this way are popular - 3M download in last month, yarnpkg.com gives it a 🔥 . I say this is supportive evidence for webpacker making it a sensible default.

webpack/shared.js

{
    test: /\.css$/,
    use: [ 'style-loader', 'css-loader' ]
}

components/my_component.jsx.erb

import css from '<%= File.join('..', '..', '..', 'node_modules', 'my_node_module', 'dist', 'my_node_module.css') %>'

The only downside is that this approach seems to slow down the ./bin/webpack with the need for the erb to be processed.

Looking forward to learning from the PR on this!

[justin808]

@sealocal the point of `import css from './MySuperComponent.css' is to have small bits of CSS right next to the components. If you want a global set of styles, just set it in the header and be done with it.

[gauravtiwari]

@sealocal Great 👍 I think we are on the same page then 😉

Right, I see. Btw, you don't need to do .erb there, just relatively link the node_module as you would link any node_module. For ex - import('dialog-pollyfill/dist/style.css') - just make sure the path is correct. You see, we are exposing the node_modules folder in our webpack config anyway so, everything under that is exposed for you to load in your components. All, you need is appropriate loaders so, it doesn't start complaining that "I don't know what are your taking about" 😄 That's the whole point for loaders. Loaders is like training webpack to know and process a particular language and it's features, in this case it's css.

Please do checkout this in the meantime -
https://github.com/gauravtiwari/webpacker-example-app/blob/master/config/webpack/shared.js#L78

Most of the work is on this repo and for guide just use this comment - #109 (comment)

[snuggs]

This is awesome! And great to see how to get into the innards of how to integrate with Rails.

[sealocal]

@justin808 I really don't care if it's global or local. I just want the stylesheet to always be available for any page or component that renders app/javascript/components/my_component.jsx.erb. The component depends on a node_module, that includes a default stylesheet. I just want to prevent future display bugs that could occur if someone updates the node module. The packaged stylesheet will always be at a location of /node_modules/my_node_module/dist/my_node_module.css within my app. Most of my layouts will not use this component, but some will, and it does, I don't want to remember to add the stylesheet to that header. I could be "doing it wrong," but I think this is the simplest way for me and for now.

@guilleiguaran I get it! I don't know why you use import(...) while I use import ... from ..., but yes, I was able utilize the resolved node_modules path! Thanks!

[gauravtiwari]

@sealocal Ohh, it's because we don't need to assign that import. The assignment is only used if we want to do anything further with that variable. Essentially css below is just a variable that has inherited value from that import,

import css from 'file.css'

It's ok like this if you are using css variable anywhere in the component, but I think you are not, right? So, just using import('...') will suffice. The above is mostly required in the case of JS modules. We do import React from 'react' because we need React variable to be used further in the component.

Sorry, if I confused you earlier :)

[justin808]

I don't know why you use import(...) while I use import ... from ..., but yes, I was able utilize the resolved node_modules path!

import css from './MyCompnent.css';

is for CSS modules where the class names in MyComponent.css are made into unique hashes so that your class names in your JS code are clean and simple, yet the browser has a totally unique class name that will not conflict.

[rstacruz]

Yes, I'd love to see this as well. This way we can use bootstrap-sass (and other frontend CSS tools) without having to resort to rails-assets.org, or dumping them into vendor/, or other hackish workarounds like that. I know there's a bootstrap-sass gem, but as a maintainer of frontend OSS projects, I don't want to publish a gem for every little CSS/JS that I do.

Our current solution to integrate Webpack (and other tools) is this:

• https://github.com/rstacruz/npm-pipeline-rails

[gauravtiwari]

@rstacruz Feel free to checkout this PR when you have a chance - #153.

[gauravtiwari]

@dleavitt #153 is merged so, we can close this one 🎉