search

cpliakas / php-project-starter

A command line tool that allows developers to quickly create PHP applications that use common conventions and best-in-breed development tools.
MIT License
75 stars 23 forks source link

Usage of a skeleton repository+a few ideas #47

Open sagikazarmark opened 9 years ago

sagikazarmark commented 9 years ago

I find this tool amazing, but has a few features not suiting into my workflow (which is not but, just writting a comparison here).

I currently have a few skeleton repositories based on the project type: for example I have one for PHP packages, one for FuelPHP packages, one for Grunt-based html/js packages, etc.

It would be great if this project starter could:

  1. rely on a skeleton repository
  2. be PHP project independent (meaning the project language does not matter, preferabily PHP)
  3. have a configuration in eg. home directory for storing author name, usual license, etc
  4. support TLDR Legal upcoming public API.

Sorry for writtin this all here. If any above makes sense for you, you could split this up into several parts. I am happy to contribute.

cpliakas commented 9 years ago

Thanks for the ideas.

Regarding point 3, I think this is a great feature request that should be generic to all options. This would be a great contribution that we could roll into 0.3 branch since it wouldn't require a major refactoring.

Regarding point 1, I also think this would be a great feature to add, maybe targeting for 0.4 since it would likely require changing some of the guts, but my assumption should be challenged.

Regarding point 2, it isn't documented anywhere but that is the longer term goal of the project. I have a https://github.com/cpliakas/drupal-distro project that would be a great candidate rolling into this tool, and I think the others you mentioned would be a great addition as well. Regardless, we should think through practically how we could make this codebase pluggable so that we not only have the framework in place to serve as a project starter for PHP / non-php applications, but we also foster the ability for people to write extension projects as well.

Regarding point 4, seems like a cool idea. Could you elaborate on how you envision this tool integrating with it?

Thanks, Chris

sagikazarmark commented 9 years ago

Well, as for point 4 there can be several solutions:

  1. Ask for a license name/code (Like MIT or GPL)
  2. Based on the skeleton repo (eg. from composer.json?)

However thinking about a skeleton repo: it should probably already container a LICENSE file.

So I would say the project itself should have two routes:

  1. Working from a skeleton repo (download files, create a new repo, replace names??)
  2. Create a package from scratch. This is where programming language dependency causes a problem, because for a ruby project you use completely different tools like for a php project. So I think this "build from scratch" should be PHP dependent (composer, travis, testing framework, LICENSE!)

To make things a bit clear:

  1. project start my_skeleton_repo path/to/new/project
  2. project start --new path/to/new/project

Or something like that...

Also, thinking about a roadmap, the order of points you mentioned would be the greatest. I think this license thing and PHP independency is less important.

What I do now is using the Fetch plugin with sublime text and choosing one of my skeleton repos. Using a command line application to pull from a repo (and probably replace package name, etc) would be really awesome.