OpenEMR takes big development step with composer and npm

Interesting, here is the line on the above build:

const DOCTRINE_NAMESPACE_CACHEKEY = 'DoctrineNamespaceCacheKey[%s]';

Let me try the build in alpine 3.8 (php 7.2) to see what happens there.

Hi @sunsetsystems ,

The build in alpine 3.8 (php 7.2) also works when run in php 5.6:

And still have line:

const DOCTRINE_NAMESPACE_CACHEKEY = 'DoctrineNamespaceCacheKey[%s]';

I could turn on the demo farm 18.04 development demo to build a package for download, which we can then download and check whether that line of code has a public in it.
Just let me know if you want me to do that.


ok, couldn’t help myself. Here’s the package build on ubuntu 18.04 (on a docker in the demo farm):

Looks like is using the correct line:
const DOCTRINE_NAMESPACE_CACHEKEY = ‘DoctrineNamespaceCacheKey[%s]’;

My web server is also running PHP 5.6.37. I’m very puzzled that you’re not getting the “public” modifier.

I can tell you I installed composer (and npm) from the Synaptic package manager, wondering if that matters. Yes Mint 19 is based on Ubuntu 18.04 so that test may be worthwhile.

In your composer.lock file, what version do you see for:

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