feat: esbuild support for addWatchFile and getWatchFiles

[edemaine]

🔗 Linked issue

53 (for esbuild)

❓ Type of change

• [x] 📖 Documentation (updates to the documentation, readme, or JSdoc annotations)
• [ ] 🐞 Bug fix (a non-breaking change that fixes an issue)
• [ ] 👌 Enhancement (improving an existing functionality like performance)
• [x] ✨ New feature (a non-breaking change that adds functionality)
• [ ] 🧹 Chore (updates to the build process or auxiliary tools and libraries)
• [ ] ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

This PR adds this.addWatchFile support for esbuild in the context of hooks resolveId, load, and transform.

• The implementation is similar to how this.warn and this.error were already implemented, which is to build an array for the hook context and then return it from the esbuild hook.
• To support resolveId, I had to .call resolveId with this set to the actual context, whereas previously resolveId was called with this set to the options object. I believe the new behavior aligns with the Rollup spec.
• I factored out a createEsbuildPluginContext helper because we needed it for both resolve and build.

I also added a basic this.getWatchFiles() which returns the current array of watched files added via this.addWatchFile.

• My understanding is that this doesn't match the Rollup spec of returning all watched files, including implicitly watched files. I've added a note to the README accordingly.
• But this behavior seems better than nothing / the current behavior of returning the empty array.
• I could also remove it if this seems too partial an implementation.

Context:

• We need this.addWatchFile for a transpiling unplugin because resolveId returns a not-real filename (with added .tsx extension to force the output to behave like TypeScript).
• Also because esbuild only automatically watch files with a context of "file", and unplugin sets the context to the plugin name, so esbuild --watch currently doesn't work at all.

I also removed some accidental (I think) modification of the context object via Object.assign.

I have tested this in the context of our unplugin, but I'm not sure how to write tests for this within the current testing infrastructure.

📝 Checklist

• [x] I have linked an issue or discussion.
• [x] I have updated the documentation accordingly.

[sxzz]

LGTM, @antfu could plz you review together?

[edemaine]

@antfu This should be ready for re-review when you get a chance. Thanks!

[edemaine]

Any chance this could be merged and released? It's a bottleneck for Civet now, and I'd prefer not to depend on a fork.

Alternatively, I could remove the changes to resolveId if they're too controversial, and just keep the changes for esbuild in load, which is what we really need (because this is the only place addWatchFile is supported across all build systems.

[edemaine]

Thank you!!