OpenEMR takes big development step with composer and npm


(Brady Miller) #21

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


(Rod Roark) #22
       "require-dev": {
            "doctrine/cache": "1.*",
            "phpunit/phpunit": "^5.7"
        },

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


(Brady Miller) #23

note this line is wrong (curl -sL https://deb.nodesource.com/setup_8.x | bash
); let me get you a better line before you try it


(Brady Miller) #24

Here’s the line when not running under root user:
curl -sL https://deb.nodesource.com/setup_8.x | sudo -E bash -


(Brady Miller) #25

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

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

(Rod Roark) #26
        "name": "doctrine/cache",
        "version": "v1.6.2",

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


(Brady Miller) #27

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.


(Rod Roark) #28

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

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


(Rod Roark) #29

OK it’s working now, thanks!

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


(Brady Miller) #30

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 ?


(Rod Roark) #31

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


(Daniel Sandoval) #32

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.


(Brady Miller) #33

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:


-brady


(Rod Roark) #34

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


(Robert Down, BSN, RN) #35

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