Configure build output folder structure

[etcd]

Feature Request

It would be great to have options to configure the folder structure of the build output via wxt.config.ts. For instance, I'd like to specify that built code gets output to build/src/*, instead of the current output into the top-level: [build/chunks/*, build/content-scripts/*, build/background.js, popup.html, ...]

Is your feature request related to a bug?

N/A

What are the alternatives?

The alternative is that I write a script that transforms the build output into my desired structure. From some simple manual testing, I think I can just move the build files into my desired folder, src/, and prepend src/ to the appropriate paths specified in manifest.json and popup.html.

But in general, I think this is a useful option to expose. I think it may also be easier to accomplish and less fragile if supported on the wxt side.

Additional context

I'm building an iOS Safari extension in Expo, and the library I'm using to roll the extension into the iOS app only accepts this specific folder structure (it's the react-native-safari-extension Expo plugin):

MyExtension/
├── src/
├── assets/
└── manifest.json

[aklinker1]

What tool are you using to bundle the safari extension with the native app? I've used Apple's safari-web-extension-converter and it works just fine with WXT.

https://developer.apple.com/documentation/safariservices/safari_web_extensions/converting_a_web_extension_for_safari

[aklinker1]

What tool are you using to include the safari extension with the native app? I've used Apple's safari-web-extension-converter and it works just fine.

https://developer.apple.com/documentation/safariservices/safari_web_extensions/converting_a_web_extension_for_safari

[etcd]

I'm using the react-native-safari-extension Expo plugin (updated the main post to be more clear). Since I'm building with React Native / Expo, I have no need to touch xcode so far. Ideally it can stay that way :) the method you linked to is definitely valid, for those who are developing apps natively.

[aklinker1]

https://react-native-safari-extension.vercel.app/extension-files

Posting this link so I don't have to look it up again.

I'll consider it, but I think you should start writing a script to move all the files and update the manifest. That will be the best solution for the short-term.

[etcd]

Would you consider integrating polar.sh into this project? If there was a bounty attached to this feature request, could I convince you to prioritize this feature?

For reference, here is an example of a project that integrates Polar in their issues, and screenshot below:

[aklinker1]

I might consider adding it, but that won't change my mind on this issue in particular. Even if someone were to come in and implement this, it would be on me to maintain it going forward, and this doesn't seem useful enough to me.

Could you share more of why you're using WXT in the first place? It seems like react-native-safari-extension comes with built-in devtools and isn't supposed to work with pre-built code like what WXT outputs. It seems to do some level of bundling itself.

Is there not a way to tell it to use an already built folder instead?

[etcd]

The DX of WXT is extremely good for multi-browser extension development, and it's better maintained and more mature. The suggested workflow of react-native-safari-extension is also pretty janky. Of course I don't need to tell you that WXT is an oasis in the cross-browser extension development world. And anyway, I already have an extension built using WXT - I just want to use that same codebase but bundle it into an iOS app.

Is there not a way to tell it to use an already built folder instead?

Well that's essentially what I'm doing now to get it to work (although there's still problems that I haven't looked into yet). I'm just taking the build output of WXT, transforming some paths, and letting react-native-safari-extension package that into the app.

[aklinker1]

Oh I see, sorry. For some reason I talked myself into thinking that you're reusing your react-native code for the popup, but really you're just shipping a separate extension alongside a desktop app. I see. So, yeah, it makes sense why you'd want to use WXT.

Hmmmmmmmmmmmmm... Ok, I'll see what I can do.

---

There are 4 places that dictate "where" files are output to.

1. HTML entrypoints - TODO add link
2. Non-html entrypoints - TODO add link
3. chunks - TODO add link
4. assets - TODO add link

Then there's all the places that WXT "assumes" a specific output structure... While I've tried to make non-user facing, internal values like this reference internal constants, the output structure is specifically something I decided to not store constants for, since it's complex and touchy, with the assumption that I would not allow customizing it...

So even if we allow configuring those 4 places where the output structure is dictated, there's probably a lot of code that will have to be updated.

Then there's stand behaviors like the public directory that lose their meaning. I suppose you could put things inside public/src/..., and that would solve it.

So those are most of the problems I can think of. Let me spike it out and see how bad it is, and the amount of complexity for a feature like this.

[etcd]

That would be legendary. 🙏 (and ofc happy to make a donation for this if something like buymeacoffee or polar.sh is set up!)