OpenEMR takes big development step with composer and npm

brady.miller · August 27, 2018, 6:21am

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/README.md 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!!!

-brady

brady.miller · August 27, 2018, 6:31am

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

2.4 millions lines of code were removed!!

brady.miller · August 27, 2018, 6:43am

btw,

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

-brady

kofiav · August 27, 2018, 3:31pm

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

Amiel · August 28, 2018, 1:38pm

Amazing work !!!

brady.miller · August 30, 2018, 5:43am

Hi,
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.
-brady

Dallas_Clark · September 1, 2018, 12:29pm

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

https://justi.cz/security/2018/08/28/packagist-org-rce.html

Dallas

d3sandoval · September 3, 2018, 9:55pm

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

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

sunsetsystems · September 16, 2018, 1:32am

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 103.217.166.107:7978] 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 PHP: Class Constants - Manual 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?

brady.miller · September 16, 2018, 2:36am

Hi @sunsetsystems ,

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

-brady

sunsetsystems · September 16, 2018, 2:43am

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:

brady.miller · September 16, 2018, 3:21am

But 2.7.3 should be fine:
https://packagist.org/packages/doctrine/common#v2.7.3
(note composer.json specifically requests this version)

sunsetsystems · September 16, 2018, 3:37am

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

sunsetsystems · September 16, 2018, 4:42am

Alright I tried this change:

$ diff composer.json.old composer.json
11a12,14
>     "config" : {
>         "platform": {"php": "5.6"}
>     },
16c19
<         "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 103.217.166.107:8045] PHP Fatal error:
Class ‘OpenEMR\Common\Logging\Logger’ not found in
/[…]/services/VersionService.php on line 47

Thoughts?

brady.miller · September 16, 2018, 4:59am

Hi,

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?

-brady

brady.miller · September 16, 2018, 5:04am

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.

brady.miller · September 16, 2018, 5:18am

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.

-brady

brady.miller · September 16, 2018, 5:31am

ok, couldn’t help myself. Here’s the package build on ubuntu 18.04 (on a docker in the demo farm):
https://seven.openemr.io/files/openemr-cvs.tar.gz

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

sunsetsystems · September 16, 2018, 5:32am

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.

brady.miller · September 16, 2018, 5:36am

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