Enable users to specify private remote repository system other than github when generating boiler plate projects and using webpack templates.

[ghost]

What problem does this feature solve?

In our industry, it is common for enterprise companies to use private repositories and registries that are segmented from the public. Software that is able to be used by these companies may go through a white-listing process before being moved into the company's private repositories/registries to be used by internal developers.

This means, in order for companies such as these to reap the full benefits of great open source tooling like vue-cli, it's functionality needs to be able to execute without making calls over the network to a default public repository like github.

If a user could configure the tool to use a different remote repository system / registry (much like how npm allows you to change your registry from a public one to a private one), then vue-cli could be pointed to a company's internal repo, where the network calls that are made can talk to repos that have been whitelisted and approved for use.

This would provide the following benefits to the Vue community:

• Increase adoption of vue-cli tooling by making it more flexible (e.g. enabling configuration setting that aligns with many company's whitelisting and governance processes)
• Increase mass adoption of Vue framework by increasing adoption of vue-cli tooling

I saw an issue a bit ago that discussed addressing this by entering a flag and a clone url during a command that you are trying to run, but I'm not sure how much trouble developers will run into when trying to repeat commands they find online. If we could set this with a config setting, we could help them not have to think about where their tooling is communicating while developing within their company's network.

I'm not quite sure if https://github.com/nuxt/create-nuxt-app would run into a separate problem with remote network requests, or if this will potentially solve any remote requests made by that tooling.

Note: I do not represent the views of any company nor any lawyer.

What does the proposed API look like?

My proposal would be to make this a config change as easy as the way that npm handles it:

vue-cli config set repository <my private repo system URL>

[LinusBorg]

thanks for this suggestion and your enthusiasm to improve vue-cli

However I'm not sure that I totally get what your suggestion actually is about.

• You mention repositoriesand registries, which are pretty different, and we already have a --registry flag to set a different repository (see here) - which is only necessary if your default repository of npm hasn't been changed already, as you mention yourself.
• When you mention repositories:
  • Is it about git repositories to be used with vue init?
  • or about repositories for presets to be used with vue create?

If it's about templates, we consider those a legacy feature and don't intend to add any new functionality in that area. vue-cli plugins & presets are the way to go in the future.

Maybe you refer to this part of the docs about remote presets? Because those are currently only supported for github, gitlab and bitbucket, indeed.

But that's very easily adjusted for by cloning the repo locally and using this as the source of a local preset.

[ghost]

Sorry I haven't gotten back to you until now - I've been occupied w/ some other things and will need to look into this again to determine what is really needed, if the solution doesn't already exist.

Would you mind if I closed this issue and then later re-opened once I have the time to come back to the use case I was trying to get at? I basically wanted to make sure people with restrictive or private network could take advantage of the same capabilities that people w/out restrictive network could - specifically had to do with bootstrapping new project templates I THINK but too long ago to recall where I was going with this.

For now, I have a couple remaining chapters of a Vue webapp TDD book i need to finish (thanks @eddyerburgh ), then need to dig down into vue-cli and where its going.

But also... shameless plug for this issue: #2621
I am curious to see if it is possible at all to get away from those DBAD licenses. (I do believe the right incentives exist (more adoption, && protecting users of vue-cli), just not sure about feasibility of dropping them

[LinusBorg]

Would you mind if I closed this issue and then later re-opened once I have the time to come back to the use case I was trying to get at?

Sure, that's even apprechiated.