OpenEMR takes big development step with composer and npm

Also ubuntu (and I am guessing mint) do not do a good job of installing composer/npm). Recommend removing those packages and then mimicking this process to bring them in:

Let me post better instructions to this than above, since above are in a docker where user is root

       "require-dev": {
            "doctrine/cache": "1.*",
            "phpunit/phpunit": "^5.7"

OK I’ll try your method of installing composer and npm.

note this line is wrong (curl -sL | bash
); let me get you a better line before you try it

Here’s the line when not running under root user:
curl -sL | sudo -E bash -

And regarding the doctrine/cache version, am looking for this block on composer.lock:

            "name": "doctrine/cache",
            "version": "v1.6.2",
        "name": "doctrine/cache",
        "version": "v1.6.2",

That’s with my last build where I specified that version.

I wonder if you may of done a ‘composer update’, which may of then tried to increase the doctrine/cache version. If you just stick to ‘composer install’ then should be identical to main codebase builds since it is locked via composer.lock file.

Yes I did do “composer update” a couple of times.

I reinstalled composer and npm, the “public” is gone, will test in a bit.

OK it’s working now, thanks!

What did we learn, that “composer update” is bad? How is composer.lock initially created?

Check this out:

That is a bit of a bummer to hear that composer update did this to you, since I was under impression the following in composer.json would avoid issues with php 5.6:

    "require" : {
        "php" : ">=5.6.0",

Sounds like may need to do official package building and composer updating on ubuntu 16.04 (uses php 7.0) until we become more confident. Any input on this @d3sandoval ?

I saved the original composer.lock and ran “composer update” as a test, and yes it does make a ton of changes.

I’ve never had a good time with composer update. Everytime i do it… bad things happen. I much prefer to use composer install to get the saved dependencies. If something needs to be upgraded I usually:

  1. Delete the composer-lock file
  2. Manually change the composer.json
  3. Run composer install
  4. Verify that only the things I’m changing are what end up getting installed

Sorry I can’t be of my help :confused: In some projects, I just remove the composer-lock file altogether… since it’s such a PITA to debug.

hi @d3sandoval and @sunsetsystems ,
I think the change here makes thing a bit safer (ie. ensures that php 5.6 is supported) when we do composer upgrades in the future:


Thanks Brady! As noted in the PR that’s working for me.

2 posts were split to a new topic: Dropping Support for PHP ≤ 7.0