App breaks if user-agent is switched during session

[arggh]

I've noticed a quirky behavior, where the app breaks if I switch user-agents while developing. I'm guessing this is somehow related to dynamic importing and differential bundling:

1. I load the app with one user-agent
2. switch the user-agent and navigate the app, triggering a dynamic import
3. Meteor assumes something about the client, but the the assumption is wrong due to fiddling with user-agents, so Meteor ships the wrong code
4. Execution of the newly fetched code fails with an error message similar to this one:

Promise not resolved Error: Cannot find module '@babel/runtime/helpers/toConsumableArray'

That's just me guessing, though.

In my opinion it's not even an issue, more like feature instead, but this is annoying since it's really easy to trigger: try different devices either in Chrome Dev tools or Safari's Responsive design -mode while developing and it won't take long.

When the app breaks in this way, it results in a totally corrupt state, that's not easily fixed: clearing all app storage (or maybe just indexedDB?) from dev tools and a new tab is usually required.

[arggh]

Just to make it clear, this behavior isn't restricted to only when running in develop-mode, it happens in production apps as well.

[benjamn]

The IndexedDB caching of dynamic modules should happen only in production (or with the --production flag), since I found it to be confusing and unnecessary in local development. In other words, if the problem occurs in development too, that suggests to me it's not an IndexedDB problem.

This sounds like a modern/legacy mismatch between the initial JS bundle and the later dynamic import fetches, where legacy dynamic modules assume certain legacy-only modules were included in the initial JS bundle, but they're wrong about that because the initial bundle was modern rather than legacy.

Would it be acceptable if the modern/legacy status of a particular client was somehow stickier? Perhaps the initial HTTP response could set a cookie that would override any other modern/legacy logic for the lifetime of the page?

That would mean your modifications to the User-Agent would have no effect on JS module delivery, unless you cleared your cookies. You'd still be using a technically "modern" browser, though, so the stickiness would probably be fine.

[arggh]

That sounds reasonable to me, since the alternative means shipping possibly or likely incompatible code via subsequent dynamic imports. I can't think of any downsides either, as this approach should (?) work just fine, even if you start your session with a faked user-agent resulting in delivery of the initial legacy bundle and then change it to something more modern later on.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[filipenevola]

Should we have a label for issues that only affect development and not production, like, Development Only?

I don't think this issue here is going to affect real users as they are not going to switch their agents.

I understand that this also happens in production but this is never going to affect real users.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[arggh]

I understand that this also happens in production but this is never going to affect real users.

I, as a real user of many websites, sometimes fiddle with dev tools on said sites, for example to see how a layout behaves on mobile resolutions.

I'd be surprised if an app broke due to opening dev tools and switching to mobile / tablet / responsive -modes.