Generate stylesheet_packs_with_chunks_tag for packs with style dependencies

[DanielHeath]

I'm currently building up a list of which packs I'll need in ApplicationHelper and rendering them all at the end.

Some of my packs have CSS dependencies, some do not.

At the moment, each call site needs to log its JS dependencies and also its CSS dependencies. Forgetting to do so results in the CSS being dropped in production but not in development (so it's an easy mistake to make!).

It would be safer to just register the JS entrypoints and automatically add CSS packs if there are any required by that JS. I've worked around this in my application as follows:

  <%= javascript_packs_with_chunks_tag *@javascript_packs.uniq %>

  <% sheets = @javascript_packs.map {|name| current_webpacker_instance.manifest.lookup_pack_with_chunks(name, type: :stylesheet) } %>
  <% sheets = sheets.flatten.uniq.compact %>
  <%= stylesheet_link_tag(*sheets) %>

This is alright, but it doesn't raise an error for packs that don't exist the way stylesheet_packs_with_chunks_tag does. However, stylesheet_packs_with_chunks_tag raises an error if a pack exists but has no CSS dependencies.

I propose the following options:

1. A new helper named stylesheet_packs_for_javascript_chunks_tag to render all CSS dependencies of the passed JS chunks, but not raise an error if you pass a valid JS chunk that has no CSS in it.
2. Let stylesheet_packs_with_chunks_tag silently ignore valid packs which have no CSS chunks.

[jakeNiemiec]

<%= javascript_packs_with_chunks_tag *@javascript_packs.uniq %>

I would recommend putting all of the resources in a single pack. The rest of your .js files should not be in /packs or else you will get inflated build times and file sizes:

You don't want to put anything inside packs directory that you do not want to be an entry file. As a rule of thumb, put all files you want to link in your views inside "packs" directory and keep everything else under app/javascript.

---

It would be safer to just register the JS entrypoints and automatically add CSS packs if there are any required by that JS.

Webpacker does this already. Check your webpacker.yml and ensure that extract_css is false. This will prevent webpacker from separating the 2 files.

[DanielHeath]

I’ve been using webpack for over 4 years, and I’m pretty sure I want 6-7 packs for this app, with common chunks split out. Thanks, Daniel Heath

…

On 1 Aug 2019, at 4:40 am, Jake Niemiec ***@***.***> wrote: <%= javascript_packs_with_chunks_tag ***@***.***_packs.uniq %> I would recommend putting all of the resources in a single pack. The rest of your .js files should not be in /packs or else you will get inflated build times and file sizes: You don't want to put anything inside packs directory that you do not want to be an entry file. As a rule of thumb, put all files you want to link in your views inside "packs" directory and keep everything else under app/javascript. It would be safer to just register the JS entrypoints and automatically add CSS packs if there are any required by that JS. Webpacker does this already. Check your webpacker.yml and ensure that extract_css is false. This will prevent webpacker from separating the 2 files. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[jakeNiemiec]

common chunks were removed in webpack 4, and incompatible with webpacker. You can use cacheGroups for similar functionality.

As a 4-year webpack veteran, I would be happy to review a PR from you; but if there's a new feature that you want to see added, you'll need to write the code yourself. You can also send your feature idea in an email to the rails-core mailing list.

[TylerRick]

Forgetting to do so results in the CSS being dropped in production but not in development (so it's an easy mistake to make!).

It would be safer to just register the JS entrypoints and automatically add CSS packs if there are any required by that JS.

Brilliant. I agree.

It seems unfortunate that the developer even needs to remember to manually add a stylesheet_pack_tag for any javascript_pack_tag that has associated styles. Why can't it just automatically add the CSS packs that it needs? (#2343)

I guess that's what extract_css: false does, but why shouldn't it also work for extract_css: true? (#2342)

[jakeNiemiec]

Why can't it just automatically add the CSS packs that it needs?

You don't want your styles to be bottle necked behind your js in production.

I guess that's what extract_css: false does, but why shouldn't it also work for extract_css: true?

extract_css: false does not give you a <link rel="stylesheet"..., meaning that your stylesheets are not cacheable by the browser. You will also run into FOUT.

[DanielHeath]

You might want your css to be loaded from a different part of the document from the js (eg head vs end of body). Any changes shouldn’t remove that as an option. Thanks, Daniel Heath

…

On 1 Nov 2019, at 4:00 am, Jake Niemiec ***@***.***> wrote:  Why can't it just automatically add the CSS packs that it needs? You don't want your styles to be bottle necked behind your js in production. I guess that's what extract_css: false does, but why shouldn't it also work for extract_css: true? extract_css: false does not give you a <link rel="stylesheet"..., meaning that your stylesheets are not cacheable by the browser. You will also run into FOUT. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.