feat: Image loaders for component packs

[techfg]

When developing a component, a common approach to using images is:

import Icons from "./sprites.svg"
import Logo from "./logo.png"

<svg height="24px" pointerEvents="none" width="24px">
    <use xlinkHref={`${Icons}#zoom-in`}></use>
</svg>

<img src={Logo} />

Currently, when attempting to import images (e.g., svg, png, etc.), the following error is encountered during pack:

{  No loader is configured for ".svg" files: bundle/componentpacks/mypack/src/components/mycomponent/sprites.svg 0xc0009aecc0 [] <nil>}
&{bundle/componentpacks/mypack/src/components/mycomponent/index.tsx  7 18 21 import icons from "./sprites.svg" }

While it is possible to add a File and use apis (e.g., api.file.getURLFromFullName) to obtain the corresponding URL, using images natively is a common pattern in React and building a pack should support image file loaders.

[zachelrath]

Agreed! This is a very typical pattern for using SVG files in React components.

It looks like the SVGR esbuild plugin could be helpful here: https://github.com/kazijawad/esbuild-plugin-svgr

[techfg]

Yep, was thinking esbuild-plugin-svgr for SVG and there are a few different options for png/jpg/etc., possibly one that handles responsive images (see #4358).

Will need to make sure that any other assets that are generated are included in the pack - likely here but haven't looked that closely yet.

Related #4395.

[techfg]

@zachelrath @humandad -

Disclaimer: I'm still new to the uesio codebase so possibly I'm misunderstanding how "pack" works

In reviewing the current code base, it appears the approach is to invoke esbuild natively in go using the esbuild apis. This works well, however when considering additional loaders, most do not have a go implementation so they can't be used directly.

There are a few different options I believe:

1. Use node to invoke esbuild to provide ability to use JS plugins directly
2. Implement a custom solution to communicate across go & JS boundaries
3. When needing a plugin that doesn't have a native go implementation, write a version of it in go

I don't think any of these are ideal but thinking that option 1 may be the most straightforward and cause the least amount of headaches down the road. It would provide full access to the entire esbuild ecosystem.

For some background:

1. [Question] Can esbuild / Go use esbuild / JS plugins? evanw/esbuild#821
2. Support the esbuild plug-in system？ evanw/esbuild#111
3. Is it possible to use esbuild-plugin-pnp from the go build api? evanw/esbuild#1263

Thoughts on how to best approach basedd on current need for image loaders and future flexibility? Other options to consider?

Edit Another thing to consider here is potentially needing to allow users to modify the build config to support other loaders, etc. The stock implementation can support common file types but there may be needs for specifying esbuild config, adding loaders, etc. from users at some point. There is something to be said for not allowing this but also for allowing. Currently, I don't see a way where/how this would be possible in the current code and while not directly related to image loading for this issue specifically, any change in approach to calling esbuild likely should keep this in mind.