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] Clone from Remote Boilerplate/Template #99

Closed
lukeed opened this issue Jun 7, 2017 · 10 comments · Fixed by #329 · May be fixed by chagretes/preact-cli#29
Closed

[Feature] Clone from Remote Boilerplate/Template #99

lukeed opened this issue Jun 7, 2017 · 10 comments · Fixed by #329 · May be fixed by chagretes/preact-cli#29
Assignees
Milestone

Comments

@lukeed
Copy link
Member

lukeed commented Jun 7, 2017

We've tossed this idea around a few times -- this is just to officially track it.

If we are to follow in Vue's wonderful footsteps, this would look something like:

# preact init <template-name> <project-path>
$ preact init lukeed/custom my-app

I imagine that init vs create is a nice distinction to have, but at the same time, could make it a bit confusing that create is for the included boilerplate only.

Although... the next logical step/argument is to extract the included templates (4 atm) to remote locations as well.

I have a similar functionality at play in another project, so I'd be thrilled to start this! Of course, any help and/or considerations are welcomed along the way.

@lukeed lukeed self-assigned this Jun 7, 2017
@developit
Copy link
Member

I'm 100% for moving the default templates into a Github org. We'd just see that there is no / in the name and know to go to preact-cli-templates/${name}.

@lukeed
Copy link
Member Author

lukeed commented Jun 8, 2017

Correctomundo

@knight-bubble
Copy link
Contributor

knight-bubble commented Jul 11, 2017

@lukeed @developit is the work already started on this?

@lukeed
Copy link
Member Author

lukeed commented Jul 11, 2017

@knight-bubble Yup! I have the core logic in another module right now. Just waiting as we gather other features that constitute a 2.0 before I port it over.

@thangngoc89
Copy link
Collaborator

I think that we should put everything in a single repo instead, putting it in a github org with many repos won't get many reviewers

@lukeed
Copy link
Member Author

lukeed commented Jul 11, 2017

@thangngoc89 Not sure what you mean? My remote-templates feature will be part of preact-cli internals.

What I'm saying is, that I have the same logic already inside another module of mine. So, when we're getting closer to a preact-cli@2.0, I will extract the logic from my module & add it to preact-cli

@thangngoc89
Copy link
Collaborator

thangngoc89 commented Jul 11, 2017

@lukeed I was replied to @developit about this

I'm 100% for moving the default templates into a Github org

In my mind, I think he's talking about each template will be in an individual git repo, which is going to be madness (update multiple projects at once, get reviewer,...)

So feature request here: make it work with a subfolder of the git repo

@lukeed
Copy link
Member Author

lukeed commented Jul 11, 2017

Oh, I missed that / forgot that was said. 😆

@developit
Copy link
Member

developit commented Jul 17, 2017

^ subfolder is an interesting idea, and that would serve the default templates well:

preact create some-default-template foo

Creates an app "foo" by cloning github.com/preactjs/cli-templates/some-default-template

preact create user/custom-template bar

Creates an app "bar" by cloning github.com/user/custom-template

@developit
Copy link
Member

Only issue I can see (just realized this) is that it's possible we'd actually want the default templates to be version-locked to preact-cli, because they are kinda based on whatever version of the CLI you have running. For example - in a month, whatever the current default template is might not work with preact-cli@1.0.0.

Thoughts?

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

Successfully merging a pull request may close this issue.

4 participants