jonathantorres / construct Goto Github PK
View Code? Open in Web Editor NEWA PHP project/micro-package generator for PDS compliant projects or micro-packages.
License: MIT License
A PHP project/micro-package generator for PDS compliant projects or micro-packages.
License: MIT License
Reusing the composer logic to guess the author info based on the git config (name and email) might be better than adding a dummy one
The link to the contributing infos should point to the CONTRIBUTING.md
in the .github
directory.
mnapoli/project-template for inspiration.
User should have the option to specify a comma delimited string of testing frameworks to use on their project.
Validate that each one is supported. Ignore the ones that are not.
$ composer global require jonathantorres/construct
Changed current directory to E:/users/sunel.saminathan/AppData/Roaming/Composer
Using version ^1.4 for jonathantorres/construct
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.
Problem 1
- Conclusion: don't install jonathantorres/construct v1.4.1
- Conclusion: remove symfony/finder v2.7.3
- Installation request for jonathantorres/construct ^1.4 -> satisfiable by j
onathantorres/construct[v1.4.0, v1.4.1].
- Conclusion: don't install symfony/finder v2.7.3
- jonathantorres/construct v1.4.0 requires illuminate/filesystem 5.0.* -> sa
tisfiable by illuminate/filesystem[v5.0.0, v5.0.22, v5.0.25, v5.0.26, v5.0.28, v
5.0.33, v5.0.4].
- illuminate/filesystem v5.0.0 requires symfony/finder 2.6.* -> satisfiable
by symfony/finder[v2.6.0, v2.6.1, v2.6.10, v2.6.11, v2.6.2, v2.6.3, v2.6.4, v2.6
.5, v2.6.6, v2.6.7, v2.6.8, v2.6.9].
- illuminate/filesystem v5.0.22 requires symfony/finder 2.6.* -> satisfiable
by symfony/finder[v2.6.0, v2.6.1, v2.6.10, v2.6.11, v2.6.2, v2.6.3, v2.6.4, v2.
6.5, v2.6.6, v2.6.7, v2.6.8, v2.6.9].
- illuminate/filesystem v5.0.25 requires symfony/finder 2.6.* -> satisfiable
by symfony/finder[v2.6.0, v2.6.1, v2.6.10, v2.6.11, v2.6.2, v2.6.3, v2.6.4, v2.
6.5, v2.6.6, v2.6.7, v2.6.8, v2.6.9].
- illuminate/filesystem v5.0.26 requires symfony/finder 2.6.* -> satisfiable
by symfony/finder[v2.6.0, v2.6.1, v2.6.10, v2.6.11, v2.6.2, v2.6.3, v2.6.4, v2.
6.5, v2.6.6, v2.6.7, v2.6.8, v2.6.9].
- illuminate/filesystem v5.0.28 requires symfony/finder 2.6.* -> satisfiable
by symfony/finder[v2.6.0, v2.6.1, v2.6.10, v2.6.11, v2.6.2, v2.6.3, v2.6.4, v2.
6.5, v2.6.6, v2.6.7, v2.6.8, v2.6.9].
- illuminate/filesystem v5.0.33 requires symfony/finder 2.6.* -> satisfiable
by symfony/finder[v2.6.0, v2.6.1, v2.6.10, v2.6.11, v2.6.2, v2.6.3, v2.6.4, v2.
6.5, v2.6.6, v2.6.7, v2.6.8, v2.6.9].
- illuminate/filesystem v5.0.4 requires symfony/finder 2.6.* -> satisfiable
by symfony/finder[v2.6.0, v2.6.1, v2.6.10, v2.6.11, v2.6.2, v2.6.3, v2.6.4, v2.6
.5, v2.6.6, v2.6.7, v2.6.8, v2.6.9].
- Can only install one of: symfony/finder[v2.6.0, v2.7.3].
- Can only install one of: symfony/finder[v2.6.1, v2.7.3].
- Can only install one of: symfony/finder[v2.6.10, v2.7.3].
- Can only install one of: symfony/finder[v2.6.11, v2.7.3].
- Can only install one of: symfony/finder[v2.6.2, v2.7.3].
- Can only install one of: symfony/finder[v2.6.3, v2.7.3].
- Can only install one of: symfony/finder[v2.6.4, v2.7.3].
- Can only install one of: symfony/finder[v2.6.5, v2.7.3].
- Can only install one of: symfony/finder[v2.6.6, v2.7.3].
- Can only install one of: symfony/finder[v2.6.7, v2.7.3].
- Can only install one of: symfony/finder[v2.6.8, v2.7.3].
- Can only install one of: symfony/finder[v2.6.9, v2.7.3].
- Installation request for symfony/finder == 2.7.3.0 -> satisfiable by symfo
ny/finder[v2.7.3].
Installation failed, reverting ./composer.json to its original content.
Once a project is successfully created. Run the composer commands to install dependencies.
It should match the regex used by Composer:
'[A-Za-z0-9][A-Za-z0-9_.-]*/[A-Za-z0-9][A-Za-z0-9_.-]*'
Your current regex has both false positives and false negatives:
would be great to have a interactive mode where construct asks the user for all required (and also optional information) with some sane defaults pre-selected
The code namespace might not match the composer package name. It would be great to have an option to specify a different namespace (the default behavior can still be to reuse the package name to build the namespace)
The .env
file MUST
be added to the .gitgnore
file of the constructed project/micro-package.
Make it look prettier.
We should reduce the usage of magic variables (e.g. defaults in ConstructCommand).
There's currently a mixture of .. for more details.
and .. for more information.
when linking to ressources (e.g. changelog, contributing) in the README.md. Would suggest to pick one and use it consistently. Which one would you prefer?
phpunit.xml should never be checked in IMO, and might even go into gitignore, the dist file is there to provide defaults.
An optional --cli
option should enable construct to generate a CLI skeleton.
The symfony/console
component should be the default, while also allowing to inject other CLI components. After project generation a bin
directory and an initial bin script
should be present which is linked via the bin
key in the project's composer.json.
As long as the constructed projects are not setup with a requirement to measure code coverage (e.g. via Scrutinizer), as it currently is, we prolly should disable Xdebug in the constructed .travis.yml
to enable faster builds.
Same as #122, though it might be possible that the constructed package will keep/have only a private scope (Satis, Toran Proxy).
Add option to select a testing framework (phpunit, phpspec, behat) PHPUnit is the default.
would be great if construct would optionally create a LICENSE file and add a hint to the composer.json for the used license.
"your-vendor-name/package-name" results in testClass with $package-name variable, which is invalid. Converting dash to camel case would be the best solution.
Running PHPunit with code coverage would currently include all vendors in the coverage data, which is wrong, slower and can do weird things (in case one of your vendors has a CLI script as requiring the file will launch their CLI)
What's your opinion on adding an optional option to load common options settings (e.g. namespace
, testing framework
, editor config
, ...), which might be standardised for a company or organisation, from a configuration file?
-c, --configuration[=CONFIGURATION] Generate from configuration file [default: "/home/<username>/.construct"]
Which configuration format (e.g. ini
, yaml
, toml
, json
) would you prefer?
The reading flow of the README.md
could be improved by relocating some blocks ordered by their importance.
Would suggest the following order:
Also here the motivation is to reduce the manual steps left to the package author.
Currently the vlucas/phpdotenv
library is a dev requirement while it should be a non dev requirement.
I built a project on PHP 5.6.16
and in the constructed Travis file an entry for 5.6 is missing in the versions list.
Test case to reproduce:
/**
* @test
* @ticket 91 (https://github.com/jonathantorres/construct/issues/91)
*/
public function it_should_return_all_versions_to_test_on_a_php5616_project()
{
$versionsToTest = $this->travis->phpVersionsToTest('5.6.16');
$versionsExpected = [
'hhvm',
'nightly',
'5.6',
'7.0',
];
$this->assertEquals($versionsToTest, $versionsExpected);
}
Upgrade generated PHPUnit skeleton to PHPUnit 6 when the platform or specified PHP version is >= 7.0.
The current example configuration is missleading as it only should configure the namespace, the project and vendor name are set via the generate
argument.
Currently the project name is not validated correctly when using a configuration file. It should take the project name from the fed argument and the vendor name from the configuration file which combine into the project name to validate.
The Composer script cs-lint
should only be run against one PHP version on the construct
repository and in the generated projects.
The bash global environment variables introduces in f399b88 should be renamed.
disable-xdebug => DISABLE_XDEBUG
If my package works on 5.6+ I have no reason to test it on 5.4 and 5.5 per example
Just had an issue with Travis CI where the in Composer required PHP version (set via construct
) was greater than the version on the Travis CI box. Maybe we should just pinpoint the PHP version to the minor version.
To also support users opting for GitLab
, it would be useful to aid them in constructing
a package structure targeted for GitLab. This could be done by introducing a --profile
or similar named option which excepts gitlab
or github
as a value, with github
being the default.
Using the option to be e.g. --parallel-lint
or simply --lint
would add the PHP Parallel Lint package as a development dependency, add related Composer scripts e.g. lint
and lint-changes
, and add it (i.e. lint-changes
) to the Travis CI build configuration.
What's your opinion on this?
Missing composer test script for:
Currently the license
, testing framework
, and PHP version
from the configuration file are not validated.
The generated Composer script could be namespaced. With a new --composer-script-namespace
option the namespace could be injected.
When not set the Composer script namespace should be derived from the project name.
If it's a short name (<=9 characters) it should be taken as is while being lowercased.
Logger => logger
If it's a long name it should be build from the initial letters while also being lowercased. .
SomeUsefulLibrary => sul
Some-useful-Library => sul
some_Useful_library => sul
Having namespaced Composer scripts adds documentation while also introducing a typing overhead.
> composer
sul
sul:application-version-guard Run the sul:application-version-guard script as defined in composer.json.
sul:configure-commit-template Run the sul:configure-commit-template script as defined in composer.json.
sul:cs-fix Run the sul:cs-fix script as defined in composer.json.
sul:cs-lint Run the sul:cs-lint script as defined in composer.json.
sul:test Run the sul:test script as defined in composer.json.
sul:test-with-coverage Run the sul:test-with-coverage script as defined in composer.json.
sul:travis-lint Run the sul:travis-lint script as defined in composer.json.
What's your opinion on this?
Should we also namespace the construct
Composer scripts?
When using the -g
or --git
option it would be useful to create a .gitmessage
template, which follows the rules described by Chris Beams, and a Composer script for configuring it. This might raise the quaility of commit messages.
This leads to problems (like shown in the following console excerpt) when doing the composer install
.
Creating your project...
Loading composer repositories with package information
Installing dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.
Problem 1
- This package requires php >=5.6.0 but your PHP version (5.5.9) does not satisfy that requirement.
The finder should be set via setFinder
not finder
.
To avoid a confusion with the activity test
ing we should prolly rename the long option to testing-framework
, also aligns it with the used configuration key.
To reduce the manual steps left to the package author, it would be nice to have the possibility to create the GitHub repository for the constructed package.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.