How to properly setup for development and testing with composer?

[Roman]

Dear SilverStripe developers.

I'm struggling a bit with setting up a proper (local) environment for
development and I was hoping some of you could give me an insight on how
you do it.

Say, you're forking a module and want to work on that source code. My
approach so far has been to clone the repository to a directory outside
of my project, then symlink it into the project folder.

This works fine, but can mess with composer (so that "composer update"
no longer works). The proper solution would probably be to use composers
"path" repository type, but that seems to be still broken:
https://github.com/composer/composer/issues/4451

The symlink approach also causes issues when running unit-tests… there
seem to be several modules that rely on some fixed folder-structure when
it comes to unit-tests (silverstripe-framework, I'm looking at you), so
they don't work.

I guess I could add my fork as an "overlay" in composer.json, but
committing, pushing and running "composer update" sounds quite
cumbersome for fast iterations.

So, how do you do it? Is there something I missed which would solve all
my issues?

Thanks - Roman

[Gordon Anderson]

hi Roman

My normal approach is just to git clone on what I am working on in a separate branch and just don't composer update during that time.  If you require to, push your forked code somewhere, overwrite via a composer update and then clone again after removing the composer version.

If by testing you are meaning unit testing, I've found it easiest/fastest to use a clean copy of SilverStripe which is not hooked up to a webserver in anyway, with only the module in question and necessary dependencies installed.  This is similar to how Travis works.  Oh and run the tests with in memory sqlite or you will lose your patience pretty quickly :)

Cheers

Gordon

[Corey Sewell]

Hey Roman,

I use composers "Require inline alias" and and the "VCS repo" type for this.

EG composer.json
{
    "name": "my/ss-website",
    "require": {
        "silverstripe/cms": "3.2.1",
        "silverstripe/framework": "3.2.1",
        "someones/module": "dev-my-custom-branch as 3.1.3",
    },
    "repositories": [
        "someonesmodule": {
            "type": "vcs",
            "url": "https://github.com/myname/someones-module.git"
        }

    ]
}

The important parts are dev-my-custom-branch as 3.1.3 and "url": "https://github.com/myname/someones-module.git"
dev-my-custom-branch = Your branch name prefixed with dev-
3.1.3 = The version number composer will use when comparing your branch to other sources.
https://github.com/myname/someones-module.git = The GIT/GitHub URL to the repo with containing your custom branch.

The someonesmodule key in repositories is just an arbitrary name and can be what ever you want.

Run composer update, and composer will fetch your fork.
Every time you push a change to your repo, you do not have to run composer update.
You only need to run composer update prior to deployment, to ensure composer.lock is up to date.
Remember, you can run composer update someones/moduler to just update the module your working on

Then, if/when your Pull request is merged in, to start using the official package again, you simply delete:
dev-my-custom-branch as
and
"someonesmodule": {
   "type": "vcs",
   "url": "https://github.com/myname/someones-module.git"
}


Hope that makes sense and helps you out!

[Christopher Pitt]

So, there are two things you can try. 

1. Composer local filesystem dependencies. This will avoid the symlink.
2. Running composer require (to get the module into a project in the first place) and then replacing the remotes in that module folder with your fork and the correct upstream. You then run the tests in the context of the main folder, with something like vendor/bin/phpunit module/tests.
   

The second approach is how we do most stuff internally. The truth is the current testing patterns suck, when compared to other systems. But it's as much the fault of the kinds of testing we're doing as it is a lack of tooling. Many modules alter the CMS and the database. Both those things require a working, browser-accessible thing for the Behat (for example) tests to check. So the test beds we have create a working app around a module, and test with option 2...

[Mark Guinn]

Roman,

I tend to just work inline and add a remote for my fork. Sometimes I’ll also have a clean silverstripe install with only that module installed as well to test against (so basically the same as Gordon). I also use the “repositories” tag in composer quite a bit if I don’t have time to wait for pull requests to be accepted.

Mark

> --
> You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
> To post to this group, send email to silverst...@googlegroups.com.
> Visit this group at https://groups.google.com/group/silverstripe-dev.
> For more options, visit https://groups.google.com/d/optout.

[Roman]

Hey Corey

I've been using this approach to overlay my forks over other official modules.

Every time you push a change to your repo, you do not have to run composer update.

Wait, does that approach actually create a git repo in your directory where you can push from? If yes, this would be ideal and totally acceptable. Switching to the correct repo once your PR was merged, by just removing the "repositories" overlay sounds like a nice thing too.

Will test that approach asap, thanks!
- Roman

[Roman]

Thanks Gordon (and all others who replied)

How do you enable SQLite for tests? As described here: https://docs.silverstripe.org/en/3.2/developer_guides/testing/unit_testing/#use-sqlite-in-memory ?

Is there a way to set that parameter via XML (phpunit.xml)? I mean, adding it to the command-line is ok, but I'd prefer it would just use SQLite by default. 

Cheers - Roman

[Mark Guinn]

It depends on whether composer uses “dist" or “source” to check out the project. I believe the default is to use “dist" for stable versions and “source” for dev branches (3.3.x-dev etc). But you can also override it by deleting the module folder and running `composer install —prefer-source`. If it’s source though, yes it leaves a usable git repo in tact.

[Corey Sewell]

Ahh, yes and no - depending on your settings

If your first composer update/install/require included --prefer-source or prefer-source is set to true in your composer config then yes.
If your default is prefer-dist when you first ran update/install/require then I think you have to remove then re-add with --prefer-source

--

Regards,
Corey Sewell |
New Media Manager - Guru Digital Media
Phone: + 64 9 281 3157 | Mobile: 021 902 024 | Fax: 09 281 3155 |
Email: co...@gdmedia.tv | Website: www.gdmedia.tv
Postal: PO Box 103, Thames, 3540

[Roman]

I figured out how to use SQLite as a default for the tests.

First, get SQLite :)

composer require --dev silverstripe/sqlite3 

Add a switch to enable SQLite, as outlined here:
https://docs.silverstripe.org/en/3.2/developer_guides/testing/unit_testing/#use-sqlite-in-memory

In your phpunit.xml add:

<php>
    <get name="db" value="sqlite3"/>
</php>

Now things also run reasonably fast when running the unit-tests from within PhpStorm.

Thank you all for your hints and advice. I think I've gotten a big step closer to a better dev environment.
Cheers - Roman

[Gordon Anderson]

On Thu, Feb 25, 2016 at 8:00 PM, Roman <bumm...@gmail.com> wrote:

Thanks Gordon (and all others who replied)

How do you enable SQLite for tests? As described here: https://docs.silverstripe.org/en/3.2/developer_guides/testing/unit_testing/#use-sqlite-in-memory ?

i wrote that :)  Had to ask around on IRC as it was not in the documentation, hence my adding it. 

Is there a way to set that parameter via XML (phpunit.xml)? I mean, adding it to the command-line is ok, but I'd prefer it would just use SQLite by default.  

Command line only as far as I know.  However logic could be passed to config.php or preferably (as was pointed out by @tractorcow) to use _ss_environment.php to default to SQLite when tests are executed from the command line.

Cheers

Gordon 

[off...@netwerkstatt.at]

Hi all,

 

here is an example for a _ss_environment switch to sqlite:

 

http://www.silverstrip.es/blog/how-to-speed-up-unit-tests-using-sqlite/

 

In shell you can also call one test directly, e.g. using

 

phpunit --filter testNameOfMytest path/to/tests '' db=sqlite3

 

Cheers,

 

Werner

 

--

[Cam Findlay]

If you've learnt something new that you think should be part of the documentation go ahead and write something up, you can hit the edit button at the botton of the dev docs pages and quickly submit a pull request improvement. Just be sure to prefix the commit message with "DOCS" so the core committers know it's a docs only PR (it's more likely to get reviewed and merged that way).