Esbuild: [Feature] Support references to non-js assets

[tracker1]

Even if not supporting the likes of CSS transforms (sass/less), it would be nice if you added support for referencing static assets like images, etc. Can simply hold a reference, and output to the dist directory with originalname.hash.ext ... and then put the output path into the JS... that output path should probably be configurable as well... such as / (default), or /assets via configuration, etc.

This is what a lot of bundlers are doing for most things. Inlining and (s)css support would probably be natural followup support.

[evanw]

This isn't exactly what this issue describes, but in case it's useful: I've since implemented a feature where you can load an arbitrary file type as a string using the --loader flag. For example, to enable importing .yml files as strings, you could pass --loader:.yml=text to esbuild.

[tracker1]

@evanw that's a decent first step... however I do think that transformers and some sort of esbuild.config.js in the cwd would be prudent for specifying these things... namely setting up a transformer for a file type.

// esbuild.config.js
const fs = require('fs');

module.exports = {
  transforms: {
    '.yml': filePath => Promise.resolve(fs.readFileSync(filePath, 'utf8'))
  },
}

Where each definition is a file extension, and the value is a function, or async function... if a promise/thenable is returned, wait for the result and use it, or blow up if rejected?

From here, one could just '.yml': require('esbuild-transform-plain-text'), or similar... actually attaching what they want as their own transformers. expecting cwd to be the project/root.

[tracker1]

It'd be a bit more explicit/basic than say webpack, but at least allow for the flexibility.

[tracker1]

or maybe loaders instead of tranform

[maraisr]

Id love to see something like this - especially build time stuff to support tooling like Treat.

[shunia]

Without this I can not even just try how esbuild will work on my projects. Lots of required file path to be dynamic loaded (json, png, jpg, etc.).

[rgbdelta]

@evanw I was playing around with a loader I made that packages assets and gives them a unique name under /assets in the bundle directory but I had to first add a property the parseResult struct which to provide an optional output path for asset files. I figured that the loaders should determine whether they need to output any files or not.

After a file is parsed, I commit the file operations to copy over the assets within the ScanBundle function according the to asset loader's parse results. Or should file operations just occur within the loader switch case under parseFile? If so then there doesn't need to be any modifications to the parseResult struct.

Do you know how you would want to go about configuring the packaging of asset files?

What I currently have is a an asset loader that packages common files like .jpg, .png, .svg, .mp4, .webm by default. But you would probably want a configuration file for the user to configure which loader they want, correct? They can still do it via command line but I can see this becoming too much for a command.

[evanw]

Heads up that I'm currently in the middle of a rewrite of the bundler to support tree shaking, ES6 modules, and code splitting. So now might not be the best time to consider contributing to the bundler.

Or should file operations just occur within the loader switch case under parseFile?

The file system is deliberately abstracted away from the bundler to make it easy to test, and also to make it easy to run in API mode without touching the file system. Any necessary information to complete the operation should be added to the bundle and made available for tests to inspect, but the actual file operations should only be done after bundling is complete.

I assume you'd have to attach some extra information to parseResult, then have the bundler emit instructions for file copy operations somehow.

Do you know how you would want to go about configuring the packaging of asset files?

If loaders need configuration information, I'd like for that to be provided in a consistent way for all loaders, not just for asset files. I haven't decided how that will work yet since no loaders currently need configuration.

you would probably want a configuration file

The way to do this with esbuild is to invoke the bundle() API from a JavaScript file. That takes the same options as the command-line tool but as a JavaScript object literal, like a configuration file.