OpenEMR takes big development step with composer and npm


(Brady Miller) #1

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


Error in Step 4 of installation of OPENEMR
(Brady Miller) #2

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

2.4 millions lines of code were removed!!


(Brady Miller) #3

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


(Victor Kofia) #4

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


(Amiel Elboim) #5

Amazing work !!!:clap::clap:


(Brady Miller) #6

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) #7

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


(Daniel Sandoval) #8

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


(Rod Roark) #9

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 https://secure.php.net/manual/en/language.oop5.constants.php 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) #10

Hi @sunsetsystems ,

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

-brady


(Rod Roark) #11

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) #12

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


(Rod Roark) #13

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


(Rod Roark) #14

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) #15

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) #16

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) #17

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) #18

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]’;


(Rod Roark) #19

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) #20

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