Improved inline script support

[delucis]

Summary

Adding support for minification and TypeScript to <script is:inline> would improve authoring experience and output performance.

Background & Motivation

Astro has an is:inline directive for script tags that prevents a tag from being bundled and hoisted. Currently, the contents of an inline script are not processed at all and shipped verbatim to the browser.

One common use case for inline scripts is to ensure some code executes at a specific point in the page load lifecycle. The classic example is colour scheme preference, where an inline script should execute and set a dark/light mode preference as early as possible to avoid a flash of the incorrect colour scheme.

Astro’s current behaviour means you are forced to write your inline script in plain JavaScript and (ideally) author it in a fairly terse way, because all comments etc. will be shipped to users as is. This makes for a less good authoring/maintenance experience, but also for a worse end-user experience if they have to download larger than necessary script tags.

As an example, Starlight has multiple places where it uses inline scripts to control page behaviour during the page load lifecycle and each of these needs to be authored carefully and in a less maintainable way to avoid shipping overly verbose inline code.

Goals

• To reduce the size of JavaScript shipped to end users even when it is inlined.
• To support better authoring practices in inline scripts.

Example

The proposal here would be to process inline scripts without bundling and hoisting them. Ideally this would include support for TypeScript types as well.

For example, a user might author:

<script is:inline>
/** Multiply a number by five. */
const timesFive = (variable: number) => {
  const constant = 5;
  return variable * constant;
};
</script>

And the build output could look something like:

<script>const timesFive=(a)=>a*5</script>

This would enable people to author with inline comments, expressive variable naming, types, etc., while still shipping a minimal script with the same functionality to the browser. (This would need to use a minification pipeline that respects the behaviours of global HTML scripts, e.g. in the example above the timesFive identifier will be attached to globalThis, so should not be minified in case another script somewhere is relying on it.)

Other restrictions of inline scripts would still apply. For example an import statement would not be bundled.

[matthewp]

What happens if someone does:

<script is:inline src="https://somecdn.com/myscript.js"></script>

[delucis]

Nothing I think? There’s probably a similar question around:

<script is:inline set:html={`console.log(${serverVariable})`}></script>

[delucis]

One option could also be to basically split behaviour into three tiers:

• <script> — bundled, emitted, as currently
• <script is:inline> — processed, but injected inline
• <script is:raw> — for when you really want something Astro doesn’t touch (works today already)

[sommerper]

Completely agree. The worst part is that setting define:vars makes it inline an invalidates all the types that I've written and I have to rewrite my code.

Basically I can't ever be 100% sure that I can use typescript if I suddenly find myself in need of a server defined var.

[delucis]

Adding another motivation for us to think about: CSP support. Currently, inline scripts are not handled by Astro's CSP feature. Moving these to be processed might give us the opportunity to automatically add hashes for people rather than forcing them to move to a very manual approach if they want to enable CSP.

[Adammatthiesen]

Expanding on this idea, plus my own wants/desires... it would be nice if we could have a proper way to pass vars to in-lined scripts... #995 (reply in thread) I've never tried to do something like this... but it would be nice if we could get a define:vars for in-lined scripts that still permits some processing.

Not everyone on my team is convinced that custom web elements is a great idea... 😅 and that tends to be the best way currently to get custom data easily on a mass scale