Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Allow to filter chunks when using javascript_packs_with_chunks #1944

Closed
somebody32 opened this issue Feb 14, 2019 · 5 comments
Closed

Allow to filter chunks when using javascript_packs_with_chunks #1944

somebody32 opened this issue Feb 14, 2019 · 5 comments

Comments

@somebody32
Copy link
Contributor

We're using multiple entry-points on some of our pages and we've configured webpack to create only one runtime chunk across all of them with runtimeChunk: "single" to save space and minimize files.

But then there is a problem when using javascript_packs_with_chunks because it includes all chunks for the entrypoint and the runtime one as well. So that could lead to the case when runtime chunk is executed multiple times which generates unpleasant side-effects.

For now, I've created my own version of javascript_packs_with_chunks that allows filtering runtime chunk but I'm questioning the need to have something like that in webpacker itself.

module WebpackerHelper
  def javascript_packs_with_chunks_without_runtime_tag(*names, **options)
    sources = sources_from_manifest_entrypoints(names, type: :javascript)
    sources_without_runtime = sources.reject { |s| s.include?("/runtime-") }
    javascript_include_tag(*sources_without_runtime, **options)
  end

  private

  def sources_from_manifest_entrypoints(names, type:)
    names.map { |name| current_webpacker_instance.manifest.lookup_pack_with_chunks!(name, type: type) }.flatten.uniq
  end
end
@jakeNiemiec
Copy link
Member

Consider my recommendations here: #1835 (comment)

@somebody32
Copy link
Contributor Author

@jakeNiemiec your recommendations are valid if we're talking about user chunks, but in my issue I was talking more about runtime one which webpack is generated. The other approach would be just to include it into every chunk, but this is just a step back in terms of optimizations

@jakeNiemiec
Copy link
Member

Let me illistrate how we do it:

thing.html.erb

<% @lazy_chunks[:thing_show] = true %>

JS in <head>

<script>
  //...
  window.thingShow = <%= @lazy_chunks[:thing_show].present? %>
</script>

JS in runtimeChunk

if (lazyChunks.thingShow) {
  import(/* webpackChunkName: "thingShow" */
    /* webpackMode: "lazy" */
    './thing/thingShow.index');
}

Basically, we use a single slim entry point as a "hub" for loading desired chunks.
✅ only one runtime
✅ only load what you need
✅ hub chunk is loaded fast with sub-chunks loaded in parallel afterwards
✅ excellent tree shaking and auto-splitting for chunks

Not for everyone, but helpful enough for me to share when I can (even though it goes against some of webpacker's design decisions).

@jakeNiemiec jakeNiemiec mentioned this issue Apr 1, 2019
Closed
@nickytonline nickytonline mentioned this issue May 3, 2019
Closed
4 tasks
@rossta
Copy link
Member

rossta commented Jun 7, 2020 •
edited
Loading

@somebody32 I'm late to the party here, but I want to understand the problem better.

So that could lead to the case when runtime chunk is executed multiple times which generates unpleasant side-effects.

I agree this would be unpleasant. One way I could see this happening is if javascript_packs_with_chunks_tag is included more than once on the page, say once in the layout, and another in a specific view template. Is this the kind of use case you're referring to?

It would be nice if webpacker provided helpers to aid with this, which also typically would mean you'd want to set runtimeChunk: 'single' for the splitChunks optimization. See this comment for more details: #2039 (comment)

@guillaumebriday
Copy link
Member

Thanks @rossta and @jakeNiemiec for the suggestions! 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@rossta @somebody32 @guillaumebriday @jakeNiemiec