Import assertions to customize import loader

[sergiodxa]

Proposal

Let developers use import assertions (Stage 3 feature) to customize what file loaders to use in order to let them use more than just the predefined list of supported files

Background

There have been many case where people ended up sending a PR to add a new file extension to the list of loaders here

remix/packages/remix-dev/compiler/loaders.ts

Lines 4 to 40 in fd00bc6

	export const loaders: { [ext: string]: esbuild.Loader } = {
	".aac": "file",
	".avif": "file",
	".css": "file",
	".eot": "file",
	".flac": "file",
	".gif": "file",
	".gql": "text",
	".graphql": "text",
	".ico": "file",
	".jpeg": "file",
	".jpg": "file",
	".js": "jsx",
	".jsx": "jsx",
	".json": "json",
	// We preprocess md and mdx files using XDM and send through
	// the JSX for esbuild to handle
	".md": "jsx",
	".mdx": "jsx",
	".mp3": "file",
	".mp4": "file",
	".ogg": "file",
	".otf": "file",
	".png": "file",
	".sql": "text",
	".svg": "file",
	".ts": "ts",
	".tsx": "tsx",
	".ttf": "file",
	".wav": "file",
	".webm": "file",
	".webmanifest": "file",
	".webp": "file",
	".woff": "file",
	".woff2": "file",
	".zip": "file",
	};

.

I think Remix could use the import assertions to let developer tell Remix how to load those imported files.

Use Case

• Support importing practically any file
• Avoid keeping an ever growing list of file extensions
• Possible provide build-time optimizations using loaders

API/Examples

Let's imagine a developer wants to use GraphQL, but because queries are long it wants to move them to a .gql or .graphql file, after importing them the developer wants to get a string with the value of the query, using import assertions it could do

import query from "~/queries/get-user.gql" assert { type: "text" }

export async function loader({ params }) {
  let data = await runGraphQLQuery({ query, variables: params }})
  return json(data)
}

The magic part is the assert { type: "text" } which is how the developer is telling the Remix compiler "treat this file as a plain text file".

The same developer could do the same later to import an SQL query too

import query from "~/queries/report.sql" assert { type: "text" }

export async function loader() {
  let data = await db(query)
  let pdf = await generatePDF(data)
  return new Response(pdf, {
    headers: {
      "Content-Type": "application/pdf"
    }
  })
}

Now, imagine you're coding a WebWorker, you need the path to the JS file so you can initialize it like new WebWorker("file.js"), if you try to import it normally Remix could consider any JS file a JS module but here the developer want the hashed URL to that file, so the developer could use the type: "file" to tell Remix to treat this import as a file and gives you back a hashed URL, as with images or fonts.

import webWorker from "~/web-worker.js" assert { type: "file" }

// inside a component
useEffect(() => {
  let worker = new Worker(webWorker)
  worker.postMessage(data)
}, [data])

Provide build-time optimizations

Remix could also provide some pre-defined loaders that optimize the imported file, in prior version Remix used to optimize images at build-time using the img: prefix on the import path

import guitar from "img:~/guitar.jpg?quality=80&srcset=720,1080,2048&placeholder";

With import assertions and image could be imported as

import guitar from "~/guitar.jpg" // gets a hashed file name
import guitar from "~/guitar.jpg" assert { type: "file" } // same
import guitar from "~/guitar.jpg" assert { type: "image" } // optimize it

The import type image can serve as a way for the developers to ask Remix to optimize this image on build-time, because doing this will make build slower the default should be to simply hash the file name

Adding to this using import evaluator attributes it should be possible to let developers customize the optimizations

import guitar from "~/guitar.jpg" assert { type: "image" } with {
  quality: 80,
  srcSet: [720,1080, 2048],
  placeholder: true
};

And following this idea, Remix could provide more loader types for developers to use, for example a worker type for WebWorkers

// get a WebWorker instance, only client-side
import worker from "~/workers/foo.js" assert { type: "worker" }
// inside an use-effect
worker.postMessage(value)

[machour]

Does this also works for imports from node_modules? ie, would it solve #1909 ?

[josh-sanger]

This would be useful for exploring libraries that use proprietary file types such as Spline.design (uses .splinecode). Interested in seeing this come to life.

[ryanwilsonperkin]

I'm +1 to this approach as well, import assertions feel like the "right" approach here, in the meantime I've proposed a temporary solution for loading arbitrary file types using the .file extension which can hopefully cut down on the number of issues/PRs created to just add a particular type to the list of loaders. #6129