jonathantorres / construct Goto Github PK

Currently the license, testing framework, and PHP version from the configuration file are not validated.

mnapoli/project-template for inspiration.

Once a project is successfully created. Run the composer commands to install dependencies.

phpunit.xml should never be checked in IMO, and might even go into gitignore, the dist file is there to provide defaults.

The link to the contributing infos should point to the CONTRIBUTING.md in the .github directory.

Currently the vlucas/phpdotenv library is a dev requirement while it should be a non dev requirement.

Upgrade generated PHPUnit skeleton to PHPUnit 6 when the platform or specified PHP version is >= 7.0.

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

If my package works on 5.6+ I have no reason to test it on 5.4 and 5.5 per example

To avoid a confusion with the activity testing we should prolly rename the long option to testing-framework, also aligns it with the used configuration key.

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:

• it accepts package names starting with an underscore
• it rejects package names containing a dash
• it rejects package names containing dots

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.

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.

• Guidelines (PSR-2)
• Issue tracking

The current example configuration is missleading as it only should configure the namespace, the project and vendor name are set via the generate argument.

"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.

I have two other composer packages globally installed (namely fabpot/php-cs-fixer and laravel/installer) that have "symfony/console": "~2.3" as their requirement.

What is the best way to go about this?

Same as #122, though it might be possible that the constructed package will keep/have only a private scope (Satis, Toran Proxy).

The reading flow of the README.md could be improved by relocating some blocks ordered by their importance.

Would suggest the following order:

• Running test
• Licencse
• Changelog
• (Code of Conduct)
• Contributing

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.

$ 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.

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.

We should reduce the usage of magic variables (e.g. defaults in ConstructCommand).

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?

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.

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.

The Composer script cs-lint should only be run against one PHP version on the construct repository and in the generated projects.

Make it look prettier.

https://travis-ci.org/jonathantorres/construct/jobs/96497447

😢

Missing composer test script for:

• phpspec
• behat
• codeception

The .env file MUST be added to the .gitgnore file of the constructed project/micro-package.

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?

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.

https://travis-ci.org/jonathantorres/construct/jobs/96497450

😞

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?

Add option to select a testing framework (phpunit, phpspec, behat) PHPUnit is the default.

The bash global environment variables introduces in f399b88 should be renamed.

disable-xdebug => DISABLE_XDEBUG

The finder should be set via setFinder not finder.

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.

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

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?

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);
    }

Also here the motivation is to reduce the manual steps left to the package author.

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.

would be great if construct would optionally create a LICENSE file and add a hint to the composer.json for the used license.

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)

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)