Hi @westonruter! is this really necessary? The scripts are enqueued when the map is built. Maybe I'm missing something because I think this might actually be disadvantageous if we do this for all widgets. We will end up with a lot of JS and CSS loaded in Customizer whether they're in use by a widget or not which will add to the Customizer loading times.
If possible, I'd love to talk for a bit in WordPress Slack whenever it's possible to you.
Cheers!

@eliorivero the scripts are enqueued when the map is built… and the page is re-loaded. If adding a Contact Info widget for the first time to the page via selective refresh, those enqueues will be called but the scripts aren't going to be printed out because the footer is not re-rendered. So this is why enqueueing the JS up-front regardless will ensure the JS is available from the moment that a widget is added to the page.

It is true that this adds additional script bloat to the page, and there are two alternative solutions that could be done, although they require more work:

1. Lazy-load the JS file when the widget is added for the first time if it is detected that the JS file is not already loaded. Actually you can see this in the original Jetpack support shim logic for the Customize Partial Refresh plugin: https://github.com/xwp/wp-customize-partial-refresh/blob/master/js/plugin-support/jetpack.js#L108-L137

2. Keep track of the scripts that are enqueued and pass them back to the client in a selective refresh response, injecting the scripts into the page if they are not already present. You can see that the foundations for this are already present in Core via the customize_render_partials_response filter. Note the comment associated with that filter and how the scripts array item is noted as being reserved: https://github.com/xwp/wordpress-develop/blob/cfd07d69cfd87fdbc53b47b8aa156df140f64f0b/src/wp-includes/customize/class-wp-customize-selective-refresh.php#L405-L435 This would be taking the same approach as Jetpack's Infinite Scroll which also keeps track of the scripts enqueued and then outputs them to the page.

So, both of these two alternatives are ultimately better in the long run, although they require more work and thought to work out. In the short term, enqueueing the JS unconditionally if is_customize_preview() seemed like a good quick win to add the initial support, without having enough time to consider all of the edge cases before 4.5 is released.

Happy to chat about this in Slack as well. 🍻

@westonruter thank you very much for the thorough explanation since it made me understand the functioning. The two examples are great and I'll definitely borrow some inspiration in the future to avoid loading everything at once. For now and given the short time before Apr 12, I agree that it makes sense to do it this way. I've started making the other widgets compatible following the approaches for the widgets in this branch.
Thanks again and have a nice weekend!