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>

[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.