Feature Request: eject ala create-react-app #15
Description
First big kudos! I love this generator and how easy it makes it to get started with a web extension, so thanks a lot!
The main problems I have with it are flexibility and lock-in.
When you start needing to customize your build setup and diverge from the sensible startup defaults provided, the single dependency on webextension-toolbox can run you into roadblocks.
Another very popular scaffold tool that took a similar approach is Facebook's create-react-app, which implements the same pattern of depending on a single package (react-scripts) to abstract away a sensible default build config.
They solve both the lock-in/customization problems with a pretty elegant solution: their eject feature, which basically copies back the whole build config from the react-scripts package into your own project so you can move forward, customize and maintain your own build config without having to fork the build tool. I feel it's a really important feature to have for any scaffolding tool taking the separate-package-for-build approach.
I see that webextension-toolbox has taken a different road with webextension-toolbox.js, which is a good middle of the road approach if your customization needs involve the webpack config (likely the most common use-case). Actually both solutions are compatible and can be complementary, as the custom webpack config can push the point where you'll need to run your own build config further into the future. But it doesn't give you nearly the same amount of flexibility and it doesn't solve lock-in. You're still heavily dependent on webextension-toolbox being actively maintained, say to upgrade the libraries, and if your setup ever diverges enough from the toolbox' sensitive defaults (which may not be so sensitive or in touch with the industry's common practices 2 years from now in the fast evolving frontend ecosystem), you're left with no easy migration path.
Their eject script doesn't look that complicated, though of course building one requires in-depth familiarity with the tool being "ejected", its structure, conventions and quirks.
So I just thought I'd take a shot at suggesting the idea here :) It's a bit of work but it has potential to be a solution to a lot of future configuration/customization requests, and reduce the lock-in burden for both users and maintainers.