Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: eject ala create-react-app #15

Open
ejoubaud opened this issue May 4, 2018 · 1 comment
Open

Feature Request: eject ala create-react-app #15

ejoubaud opened this issue May 4, 2018 · 1 comment

Comments

@ejoubaud
Copy link

ejoubaud commented May 4, 2018

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.

@HaNdTriX
Copy link
Contributor

Hey @ejoubaud

Thanks a lot for your Feedback.
I have to admit, that I am not a fan of the eject feature since it leaves the developer alone with all generator updates.

In addition to that I believe supporting both ways might be a bit overhead. Since it increases the maintenance cost of this project.

Nevertheless we can publish a blog post about ejecting manually. It is actually pretty easy since this project uses webpack for almost everything.

In the end webextension-toolbox is just a webpack runner that configures the https://github.com/HaNdTriX/webextension-toolbox/blob/master/src/webpack-config.js in a few different ways.

If you still want to have an eject feature feel free to create an extra sub generator or an npx script that just implements that.

e.g.: webextension-toolbox-eject

If it works I will create a backlink from the docs for it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants