Opt in to Webpack(er) chunk splitting

[aduth]

Why:

• Since it is the default behavior as of the upcoming Webpacker 6+ release, it will make a future upgrade easier.
  • See: https://github.com/rails/webpacker/blob/1aca8aa/6_0_upgrade.md

    • Change javascript_pack_tag and stylesheet_pack_tag to javascript_packs_with_chunks_tag and stylesheet_packs_with_chunks_tag

• It will allow for reuse of large shared dependencies (e.g. using React outside of the document capture pack without bundling a new copy of React into each pack where it is used).
  • This effort was prompted by a desire to use React outside the document capture screen (specifically to reuse the existing Alert React component)
• Conceptually well-aligned to javascript_pack_tag_once, facilitating eventual migration to render all applicable scripts once at the bottom of each page.
  • See: https://web.dev/render-blocking-resources/

[zachmargolis]

LGTM

[aduth]

A thought occurs to me: As they describe in their "old" (current) documentation, it's recommended to output all chunks at once, to best deduplicate shared groups of chunks.

Important: Pass all your pack names when using this helper otherwise you will get duplicated chunks on the page.

This could work well with javascript_pack_tag_once, so we could update all instances to use that instead. This reduces the risk of duplicate chunks. The main caveat is to make sure that the scripts would work well when output at the bottom of the page rather than inlined to where they're called. I don't expect it'd be a problem though.

[mitchellhenke]

That sounds good to me 👍🏼

[jmhooper]

Nice, this is super nifty!

The main caveat is to make sure that the scripts would work well when output at the bottom of the page rather than inlined to where they're called.

Yeah, I wouldn't expect that to be a problem either.

[aduth]

Started looking at shifting everything to use javascript_pack_tag_once. It seems mostly straightforward, but there's a few edge cases:

• The session timeout scripts assume a reference to window.LoginGov.Modal, which is not available if application script is deferred.
  • Fix is as simple as moving 'til after the subsequent render_javascript_pack_once_tags
• The shared "failure" view allows a presenter to render inline JavaScript, and there's at least one (max_attempts_reached_presenter.rb) that makes a similar reference to window.LoginGov.
  • Not sure yet how best to fix this. Will dig in tomorrow.

[aduth]

Started looking at shifting everything to use javascript_pack_tag_once.

3a96209

The session timeout scripts assume a reference to window.LoginGov.Modal, which is not available if application script is deferred.

• Fix is as simple as moving 'til after the subsequent render_javascript_pack_once_tags

ae495a4

The shared "failure" view allows a presenter to render inline JavaScript, and there's at least one (max_attempts_reached_presenter.rb) that makes a similar reference to window.LoginGov.

• Not sure yet how best to fix this. Will dig in tomorrow.

e046e1a, deferring execution until DOMContentLoaded. Tested and appears to work fine.

[aduth]

Another interesting edge case: Some packs rely on a specific order of scripts being loaded, e.g. personal-key-page-controller expected to occur after application so that it has access to window.LoginGov.Modal synchronously on script load:

identity-idp/app/javascript/packs/personal-key-page-controller.js

Line 4 in e82740a

const modal = new window.LoginGov.Modal({ el: modalSelector });

Ideally we'd have stronger dependencies defined, using imports. Another option similar to e046e1a would be to wait 'til page load to call the constructor.

I'd also thought maybe it'd be as easy as moving javascript_packs_tag_once back to the head. However, the order of where javascript_packs_tag_once is called in the markup is not always reliable. Because partials are rendered before its layout (as far as I can tell), the javascript_packs_tag_once for the application pack would always be called last.

Next best option I considered for a solution is to allow the method to receive an option to control the order that the pack is enqueued (a prepend option). See 67ef74469 and dc2273dd6.

[zachmargolis]

LGTM some small nits