OpenEMR takes big development step with composer and npm

Hi everybody,

We just brought in a commit today that requires use of composer and npm to build OpenEMR packages (to bring in 3rd party packages/assets and build the styling sheets). btw, thank you @d3sandoval for doing the huge amount of work that was required to get this.

The demos and automatically built packages already go through the needed building steps.

If you are a developer and are using the most recent codebase, then the following commands will build your openemr instance (.gitignore will ignore the built stuff):
composer install
npm install
npm run build
composer dump-autoload -o

Depending on your workflow, there are also other neat ways to build out the package for developer/tester use that we can discuss. One example is the docker environment, of which the package will be built out by one of the dockers, if needed (ie. if the vendor directory is missing):
openemr/ at master · openemr/openemr · GitHub

Also, this improvement has removed use of bower from the project (and was replaced with npm).

Again, thank you @d3sandoval for this amazing feat!!!



Just to given an idea of the scope of this work:

2.4 millions lines of code were removed!!


This is just some optional information:

If you wish to build a finished package (ie. remove a couple things that are not needed that were created in the steps above) and don’t want to rely on the official packages that are already built daily, then the following steps will do that (this is just an example is the user is root) (note that composer global is a way to install packages that are not related to openemr):
composer global require phing/phing
/root/.composer/vendor/bin/phing vendor-clean
/root/.composer/vendor/bin/phing assets-clean
rm -fr node_modules


Congrats to everyone involved :clap: :clap: :clap: Exciting stuff. Can’t wait to pull this in.

Amazing work !!!:clap::clap:

The project infrastructure has been ironed out to support these changes now. Had a couple issues in the docker demo farm, which is why it was a bit unstable last couple days, which has been fixed. And the dev docker (5.0.2-dev) now works from the new codebase.

Just a heads up on the following recent security vulnerability, be sure to update Composer / Packagist.


Thanks for posting, Brady!

There’s a new PR out now with more documentation on how to work with these tools (+ docker) locally. It’s already sped up my local development significantly :slight_smile:

Devops PR: Prevent local docker volume mount from messing with host permissions by d3sandoval · Pull Request #155 · openemr/openemr-devops · GitHub
Docs PR: New build docs by d3sandoval · Pull Request #1837 · openemr/openemr · GitHub

1 Like

I ran the composer and npm stuff in a Mint 19 system with PHP 7.2, and then installed the resulting package on a Debian 9 system with PHP 5.6. Setup worked fine but then on login this error is logged:

[:error] [pid 20729] [client] PHP Parse error: syntax error, unexpected ‘const’ (T_CONST), expecting variable (T_VARIABLE) in […]/vendor/doctrine/cache/lib/Doctrine/Common/Cache/CacheProvider.php

The offending line of code is:

public const DOCTRINE_NAMESPACE_CACHEKEY = 'DoctrineNamespaceCacheKey[%s]';

At we have this statement:

As of PHP 7.1.0 visibility modifiers are allowed for class constants.

So I seem to have a build that does not work with PHP earlier than 7.1. Does composer output depend on what PHP release it’s built with?

Hi @sunsetsystems ,

That shouldn’t happen. What version of doctrine did it install?
What is your output with composer info ?


Looks like it installed 2.7.3.

$ composer info

doctrine/annotations v1.6.0 Docblock Annotations Parser
doctrine/cache v1.8.0 Caching library offering an object-oriented API for many cache backends
doctrine/collections v1.5.0 Collections Abstraction library
doctrine/common v2.7.3 Common Library for Doctrine projects
doctrine/couchdb 1.0.0-beta4 CouchDB Client
doctrine/dbal v2.6.3 Database Abstraction Layer
doctrine/inflector v1.3.0 Common String Manipulations with regard to casing and singular/plural rules.
doctrine/instantiator 1.1.0 A small, lightweight utility to instantiate objects in PHP without invoking their constructors
doctrine/lexer v1.0.1 Base library for a lexer that can be used in Top-Down, Recursive Descent Parsers.
doctrine/orm v2.5.14 Object-Relational-Mapper for PHP

This discussion may be relevant:

But 2.7.3 should be fine:
(note composer.json specifically requests this version)

But, kinda looks like it’s not fine. Anyone else tested with PHP 5.6?

Alright I tried this change:

$ diff composer.json.old composer.json
>     "config" : {
>         "platform": {"php": "5.6"}
>     },
<         "doctrine/common" : "2.7.3",
>         "doctrine/common" : "2.6.2",

and that fixed the Doctrine errors, but now I have this error on login:

[Sat Sep 15 21:31:44.200117 2018] [:error] [pid 20726] [client] PHP Fatal error:
Class ‘OpenEMR\Common\Logging\Logger’ not found in
/[…]/services/VersionService.php on line 47



Tried on an environment that builds in alpine 3.7 (php 7.1) and tested well on 5.6 (this environment uses nginx/php-fpm via the docker dev environment):
openemr/contrib/util/docker at master · openemr/openemr · GitHub

What is the exact 5.6.x php version that you are using?


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: