multiple <script> blocks

[johndeighan]

Is your feature request related to a problem? Please describe.

I'm writing a custom preprocessor. It processes the entire file (i.e. markup) and needs to generate some JavaScript. It does that by outputting a new <script> block. Unfortunately, if the svelte file already has a <script> block, I get an error telling me that a page is only allowed to have a single <script> block. This sounds like an unnecessary restriction.

Describe the solution you'd like
A svelte page should be allowed to have any number of <script> blocks. The same should probably go for <style> blocks.

Describe alternatives you've considered
I've considered just checking if the current page already has a <script> block and just injecting JavaScript into that block. The problem is that the existing <script> block may specify coffeescript or some other preprocessor already. Then I'd have to inject coffeescript instead of plain JavaScript. And what happens if there's some other language used in the future?

How important is this feature to you?
I can work around the problem for now, but I think that a successful solution would require my suggestion be implemented.

[chuckrector]

This may not be quite what you're looking for but <svelte:head> can achieve a similar effect:

https://svelte.dev/repl/6d30c0c7269740acab724a3e0db9a189?version=3.38.2

This may be of limited value since the additional <style> blocks will not be scoped and the <script> blocks will not share component scope and other things like this. Yet I still sometimes find them useful, such as when writing a large block of unscoped utility classes or when pulling in legacy libraries. I've seldom done either outside a REPL but it's nice to have options!

[dummdidumm]

The given arguments are not strong enough to make this a consideration. If you use a preprocessor, you can do what you want but you are also on your own so to speak. If the script language is not JavaScript, you can rearrange the preprocessor execution order so that the html processor runs last, at which point the script will be preprocessed.
Adding the possibility to have multiple top level script tags would introduce too much variance for no greater benefit. It would also be confusing for newcomers to understand the semantics - is this something special that they are separated or are they treated as one? Is the order important? Etc.
I'm therefore going to close this.