Webpacker: Doesn't do .css if there's no .scss in javascript/packs

Created on 9 Jul 2018  Â·  11Comments  Â·  Source: rails/webpacker

I'm very new at webpack but... I am having the following experience:

  • running rails with Webpacker and Stimulus installed (I don't think stimulus has anything to do with the problem
  • I put a minimal application.css file in javascript/packs. I run the server, and load a page and get an error because the output file for that .css is not "compiled" and put into public/packs
  • I add a minimal application.scss and now when I run the server I see BOTH the compiled output from the .scss and the .css files in public/packs

Does that make sense? Am I misunderstanding a key thing?

Most helpful comment

So are you saying that all the packs files should be *.js and contain only imports?

Yes, that's correct. It's fine to have other files here (only if they are referenced in views) but most often assets are referenced within components so it makes sense to keep them there instead of packs folder.

So even for stimulus, I would have a stim.js in packs with just one line, import ../src/application.js right?

Yes and no, usually application.js as a name is confusing since it refers to one application and therefore, perhaps it's better to use component/controller like names. For ex:

app/javascript: 
  src: 
     components: 
       - copy-clipboard-js # import './clipboard.scss'
       - button.js # import './button.scss'

   packs: 
     - newsletter.js # import '../src/components/button' etc. 
<%# newsletters/show.html.erb %>
<%= javascript_pack_tag 'newsletter' %>
<%= stylesheet_pack_tag 'newsletter' %>
<%# rest of the view code %>

unless application itself is single-view/single-page. So, if it just has one import I would move it inside packs.

All 11 comments

@pitosalas Can't seem to reproduce this issue. You have to restart your server if you added anything to packs folder since that is main entries folder. Also, we don't recommend putting css or scss files directly into packs folder: https://github.com/rails/webpacker#usage

now when I run the server I see BOTH

What server are you using webpack dev server or on-demand compiler?

@gauravtiwari I am running in development mode, so it looks like the on-demand compiler. If I don't have either .css or .scss and I include <%= stylesheet_pack_tag 'application' %> I also get an error. Now why did I put that pack_tag in my html? Because the instructions seemed to ask me to. (I admit that this is still quite magical to me so I easily can be doing something wrong.) For example, what's a pack file? The one for stimulus looks like a standard .js file.

But I guess if I am accessing a pack that also has .css it would have created or modified my application.css? What about something like bulimia.io? It says to nom install bulma. I assume that's totally different and separate.

Anyway, however given the scenario, I can reproducibly get the behavior that I reported. My application.css has only:

html {
  font-size: 50px;
}

in it, and my application.scss is an empty file.My app/javascript/packs contains 3 files, those two and application.js.

I don't know if this is useful, but I also found that many things written in various places say/imply that you should have in your app/javascript/pack directory, two files, named application.js and application.scss. However it seems to me that having both of the files named application.* doesn't work because the compiler overwrites one with the other. I had to rename the second one to e.g. applicationstyles.scss.

app/javascript/pack is for your pack files.
Each file here is added as an entrypoint (https://webpack.js.org/concepts/entry-points/) in Webpack config.

You should not have your .scss file here, only a few .js files. In those files, you can import your code.

For example:

// in app/javascript/pack/application.js
import "../js/application.js";
import "../styles/application.scss";

Ah! I could swear I saw examples of .css or .scss in ../pack.

The thing that's confusing is importing from within java an scss or css file. How does that work out?

Also in my case, the file in question is installed with yarn in /node_modules/bulma/css/bulma.css or in /node_modules/bulma/buma.sass. What's the right way to do that?

import "/node_modules/bulma/bulma.sass";?

@pitosalas

Sure. Lets say if we have structured our app like so:

app/javascript: 
  packs: # having single pack/per view helps serve isolated and less code in the browser
     - view1.js # import '../src/styles/view1.scss'
     - view2.js # import '../src/styles/view2.scss'
     - view3.js # import '../src/styles/view3.scss'
     - so on....
  src: 
     - components
     - images
     - styles 
       - shared
         - variables.scss
       - view1.scss # @import "~bulma/bulma.sass";
       - view2.scss # @import "./shared/variables.scss";
       - view3.css # @import "basscss/base.css"; - don't need ~ for css imports from node_modules
     - etc. 
  test: 
<%= javascript_pack_tag 'view1' %>
<%= javascript_pack_tag 'view2' %>
<%= javascript_pack_tag 'view3' %>

You can also use this for relative imports: https://github.com/rails/webpacker/blob/8bcbfbce95773ca3f41b7c8314842a4a6f015cd8/docs/assets.md#using-babel-module-resolver

References:

  1. https://github.com/webpack-contrib/sass-loader#imports

Great, thanks! It's a little confusing still with all the moving parts! So are you saying that all the packs files should be *.js and contain only imports?

I see that I misread the hints for stimulus and that they say to put the application.js in src and I have it in packs!

So even for stimulus, I would have a stim.js in packs with just one line, import ../src/application.js right?

So are you saying that all the packs files should be *.js and contain only imports?

Yes, that's correct. It's fine to have other files here (only if they are referenced in views) but most often assets are referenced within components so it makes sense to keep them there instead of packs folder.

So even for stimulus, I would have a stim.js in packs with just one line, import ../src/application.js right?

Yes and no, usually application.js as a name is confusing since it refers to one application and therefore, perhaps it's better to use component/controller like names. For ex:

app/javascript: 
  src: 
     components: 
       - copy-clipboard-js # import './clipboard.scss'
       - button.js # import './button.scss'

   packs: 
     - newsletter.js # import '../src/components/button' etc. 
<%# newsletters/show.html.erb %>
<%= javascript_pack_tag 'newsletter' %>
<%= stylesheet_pack_tag 'newsletter' %>
<%# rest of the view code %>

unless application itself is single-view/single-page. So, if it just has one import I would move it inside packs.

Thank you for your time. It’s been super helpful!

Pito Salas
Brandeis Computer Science
Volen 134

On Jul 11, 2018, at 7:48 AM, Gaurav Tiwari notifications@github.com wrote:

So are you saying that all the packs files should be *.js and contain only imports?

Yes, that's correct. It's fine to have other files here but most often assets are referenced within components so it makes sense to keep them there instead of packs folder.

So even for stimulus, I would have a stim.js in packs with just one line, import ../src/application.js right?

Yes and no, usually application.js as a name is confusing since it refers to one application and therefore, perhaps it's better to use component/controller like names. For ex:

app/javascript
:

src
:

components
:
-
copy-clipboard-js # import './clipboard.scss'

   -

button.js # import './button.scss'

packs
:
-
newsletter.js # import '../src/components/button' etc.
<%# newsletters/show.html.erb %>
<%= javascript_pack_tag 'newsletter' %>
<%= stylesheet_pack_tag 'newsletter' %>
<%# rest of the view code %>
unless application itself is single-view/single-page. So, if it just has one import I would move it inside packs.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Great, no problem. Okay to close the issue?

Yes, thanks!

Pito Salas
Brandeis Computer Science
Volen 134

On Jul 11, 2018, at 9:13 AM, Gaurav Tiwari notifications@github.com wrote:

Great, no problem. Okay to close the issue?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

vtno picture vtno  Â·  3Comments

pioz picture pioz  Â·  3Comments

johan-smits picture johan-smits  Â·  3Comments

suhomozgy-andrey picture suhomozgy-andrey  Â·  3Comments

itay-grudev picture itay-grudev  Â·  3Comments