I did some first tests, and unfortunately the situation is worse now: the import of the static entry is being delayed.
The "tick" you implemented using setTimeout is creating a macrotask (https://javascript.info/event-loop). This task is allowing the browser to render already, deferring the import of the first entry. This kinda defeats the purpose of using a regular script element in the first place. In IE11, it seems to be even worse as the task is being pushed after all script tags of the page. :-/

Tomorrow, I'll test with the dynamic import, but it doesn't look good.

Thanks for testing this out. Please let me know how it works on the dynamic import cases when you can. Will see if there are any ways to shorten the microtask delay.

Released in 6.4.1. @tmsns unfortunately blocking rendering is not a goal as SystemJS follows module semantics. It might be an option to try and reduce the delay though by eg using Promise.resolve().then or another tick mechanism with a shorter delay. Please let me know if you have any suggestions here, and apologies if this messes with your use case. The previous concept should still work as an extra though that you might be able to apply manually.

Please do let me know if you can check the races here too.

So, I just finished testing and all seems to be working well 😊 Both for the races in the dynamic imports and the blocking aspect of it. I'm gonna try to promote this next week for more extended testing. 👍

Thanks for the fix!

@tmsns thanks for confirming, great to hear that!

@tmsns unfortunately blocking rendering is not a goal as SystemJS follows module semantics.

I understand what you mean., but I'd like to add a sidenote here.

When using bundlers like Rollup, one can choose the output format, eg system or es. With System, this means that every file will have the System.register wrapper. When choosing es, the resulting file can be used both in a normal script tag and a module script. When using the normal one the script can be blocking, but features like dynamic import still work.
In that sense, it would have beeen nice that code wrapped with System.register would behave in the same way as es. 😊

If you have a script that does not use import or export syntax, then use a dynamic import transform into System.import only and don't output system at all.

True, that’s the other possibility. :-)

I wonder if Rollup would be open for this kind of change...

It's very straightforward as a plugin with the renderDynamicImport hook - http://rollupjs.org/guide/en/#renderdynamicimport.

Thanks Guy! Food for a next simplification in the future.. :-)

Sorry to come back to this PR, but we have a new race issue. More specifically, when the page loads too fast, the auto-imported script is being removed from the candidates list (as the list resets: https://github.com/systemjs/systemjs/pull/2223/files#diff-b8033cc8030ffe48fef95bb6295a0c21R40). This retriggers the download and execution of the script.

Even worse, if the file has been bundled with SystemJS (as only 1 download was one of the initial advantages of the plugin), SystemJS gets reinitialized as well, breaking dynamic imports.

I was able to reproduce the issues here:
https://plnkr.co/edit/Pnpo79DZjpQL7xOg

@guybedford let me know if you want me to create an actual issue or if you need help in any way (coming up with a solution, or testing) 😊

@tmsns thanks for the replication and case here, usually better to create an issue but it's no problem. I've put together #2225 for this.