Is Electron Forge too opinionated?

Pre-flight checklist

[X] I have read the contribution documentation for this project.
[X] I agree to follow the code of conduct that this project uses.
[X] I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Problem description

Electron Forge, by default, pulls in some things that not everybody needs. The two that I've just found:

The import script always initializes a git repository if it doesn't find one. This is an annoyance for developers who are using some other version control software.
Both the import script and the quick start templates always pull in electron-squirrel-startup as a dependency. This is an annoyance for someone wishing to use other means of distribution such as the Microsoft Store where no such installer tool is needed.

Proposed solution

The Electron Forge import script and templates should not pull in stuff that some developers will then have to remove.

Alternatives considered

These could also be optional arguments to the import script for example.

Additional information

It is also worth considering the situation of someone that's quite new to Electron development. Searching for the 'best practices' will probably lead them to Electron Forge and its templates, which then proceed to pull in a whole host of technologies, for which the motivation or rationale is not really explained anywhere. It's just "This is how everybody does it and don't ask questions". I think this creates a frustrating developer experience and an unhealthy culture of "shut up and follow the pack".

I think there is an argument for strongly catering to the most common use cases. With squirrel, for example, it's easy enough to remove it and replace it with another Maker. Just edit the makers array in forge.config.js and npm uninstall the package. git is a bit harder. Some of those items could be behind flags... like --vcs <option>; ex) git (default) , svn, bzr, hg, none. Then overriding the default might be easier for people with special needs. I do like the point about better documenting the why for defaults. In my experience the electron build process is complex enough that deviating from EF's opinions can become a huge time sink. I think being strongly opinionated is a reflection of the complexity and the limited time resources of an OSS team to test permutations of the stack. In general I'm pretty comfortable accepting the "this is how we do it because it's what we can realistically test and ship" as a the unwritten reasoning, but can see the advantages to spelling stuff like that out for new comers to OSS.

electron / forge