Should imports go in <script> or <script module> ?

[KieranP]

I've been putting imports in <script> but today I needed to run a line of code once after the import, and not each time the component renders (since the library makes the config option readonly after setting it once), so I had to move the import into <script module> with the line of code after it.

And it got me thinking, where should imports really go, in <script> or <script module>? I'm guessing svelte is just hoisting all the imports up to the top level anyway, since it wouldn't make sense to import them each time the component executes what is in <script>, but does that possible cause confusion?

Would enforcing imports go into <script module> make more sense and display a warning if imports are in <script> ?

[Ocean-OS]

It wouldn't really change anything. Static imports have to be hoisted anyways. If it's a dynamic import, it doesn't have to be hoisted (but if you want it to only run once, put it in the <script module>).

[KieranP]

Yes, I figured as much. Syntactically imports might work in both types of script blocks, but semantically, wouldn't they make more sense to be in <script module>? I guess the counter argument is convenience. Having imports and code in one <script> block is cleaner.

Is there a performance improvement at compile time by providing all import statements in <script module> e.g. does Svelte just copy the contents of script module into the top of the output without any further processing, whereas having them in <script> would require it to parse the contents and figure out which ones it needs to hoist to the top?

[brunnerh]

Svelte has to parse and process everything anyway, there is no real reason to move imports around, you are just adding noise if there was no module script beforehand.

Even for dynamic imports, the browser will cache the result unless you make the path unique every time (in that case it would not make much sense to be in the module script anyway).