We’ve recently brought in mechanism for developers to use bower to bring in js/css assets into the codebase:
At this point it was just used to bring in font-awesome which is used for icons in left-nav:
My question is that should we be hard-coding the path to the assets to interface/static ? Or would it be better to make this more flexible (in case decide to migrate it somewhere else in the future) ? In that case, I could easily place the interface/static as a global setting and create a global variable to use in the path. It would be very easy to set up now rather than trying to do it later. I am asking this because Ray’s eye form brings several new css/js packages (including bootstrap) and I figured it may be best to use the new assets place (via bower) for this (but I don’t want to hard-code a bunch of paths that could change in the future).
Made the path very flexible with the following code:
So, when needed, can change the path.
Will need to ensure that use the global(and not hard-code the path) when bring in the static libraries. So, added this information to the following wiki page so we don’t forget about it : http://www.open-emr.org/wiki/index.php/Bower
Here’s Ray’s most recent branch(the eye form is awesome and is at least a year of effort by Ray; we are working out some database kinks for the install to work at this time to allow testing): https://github.com/ophthal/openEMR_2/commits/current-work-10
Looks like it is using version 3.2.0 for css that is already in library/css (this was placed for the acknowledgments screen as I recall) but then using version 3.3.4 for js that Ray’s commit places at library/js .
Oleg, would it be helpful for the possible “bootstrap” project to bring in the bootstrap-css package via bower (also includes js stuff) or is the full bootstrap package needed?
vendor -> is an indicator to everyone that code in that directory is not controlled by this project.
product -> should be commonly referred name
version -> necessary when project uses multiple versions concurrently
Under the product or version directory we typically copy all the released code from vendor. On development machines it could even include examples to make it easier to analyze interface issures.
In general vendor directories should be technology / file type agnostic so multiple products can be included without causing confusion - i.e. avoid putting jQuery under js node since jQ also requires some css files.
Sounds like the thing to think about is the version then. For example, we are just placing font-awesome in a directory and not separating/labeling it by version:
Are we planning to ask individual production installations to run any of these dependency tools? That could cause chaos since vendors are free to radically change their package structures which would break hard links in emr.
As far as versions are concerned, typical scenario would be someone contributing a cool feature using jQuery 2.1 because one of critical plug-ins needs jQuery 2.0 minimum. Would we ask that contributor to go through all uses of all previous jQuery versions and fix deprecated stuff?
MD Support, I would say no, we should not require to run bower/composer/whatever during the installation. the idea is to distribute only compiled / minified versions.
I have found a nice little script to run along with bower called bower-install. A bower.json would look like this:
We’ll need to lock components versions and it would create a structure under library/res , for example.
Then we can store library/res and forget about bower_components.
I like the idea of keeping our frontend dependencies inside of interface as that represents front end files. It’d be even better if we could have <openemr root>/public/vendor as the place for all 3rd party CSS/JS files.
As for running bower, no, we would keep everything in the codebase so the end user does not have to do any kind of bower install or composer install
I think we should avoid placing front end libraries in the library folder, that seems more for backend files. It seems like a good idea to keep our front end and back end dependencies separate.
Agree that this is meant for developers to bring in and manage the front end assets. Guessing we will be setting up composer to be used for the back end libraries(which thankfully will not be version sensitive), which will also be meant for developers to bring in and manage packages. My thought are users should definitely not have to deal with this stuff and keeping this stuff in the codebase allows ongoing testing and no surprises at build time.
Would be nice to stick to pure bower and get this working well for the font-awesome library. At this point, we need to request a specific version and place it in a version directory (ie. font-awesome//). I haven’t actually used bower and guessing many other developers haven’t, so the simpler, the better.
The path decision isn’t that big of a deal from my point of view and can be finalized or decided on later, since it can be changed via 2 changes (to the global and the path in the .bower file). Although I suppose the decision of do we need to separate the bower stuff(front end libraries) from the composer stuff(back end libraries) would be good to know.
I have been reading up on bower. Won’t supporting separate versions for the same package become very difficult if import a package that has other dependencies(for example, jquery)? Is there a possibility here that maybe bower is both overkill and not a good fit for what we need? Would it make more sense to start placing new static assets in the new directory manually in a very standardized fashion (ie. font-awesome/4-6-3/ ) ?
Another point to keep in mind is that official debian packages do not allow minified css/js files. At some point, would like to create an official debian openemr package and this will be 1 (of many) hurdles.
As I understand it, bower would see that a package it is trying to install is missing a dependency and to fetch it and place it the proper place. I’ll have to try it, but essentially bower should be smart enough to see that package A required jQuery-1.2.3 (just making up numbers here) but package B requires version 4.5.6 and grab that particular version and dump it into the bower_components sub directory of package B.
Why would Debian not allow minified versions of CSS/JS?
There is a way we could subvert that. When creating the Debian package we just run a sniffer that removed any file ending in “.min.css|js”
In my opinion, if we continue to allow to use different versions of the same package in future, it will create problems on our way to separate view from business logic. In addition it will make maintenance harder and lead to fragmentation.
There are a lot of jquery’s scattered in folders, let’s leave them there. Porting pages that use old versions may be a good task for beginner developer.
Agree there are ways we can deal with the debian problems. Note debian would also require only 1 version of jquery which is way more of a hurdle than the minified stuff. I only know this stuff because there was a developer about 2 years ago whom attempted to create an official debian OpenEMR package and appeared to give up after several months of very frustrating work.
Would bower support the following scenario(just an example):
5 separate versions of font-awesome
a package that then needed a font-awesome that was already installed (would it use the 1 already installed or would it install another in the bower_components sub directory of the package).
10 separate version of jquery
5 separate version of ui-jquery requiring separate version so jquery
Then multiple the above scenario by 100. Would things get out of hand (ie. would developers then find it much easier to manually bring in the new assets rather than mess with a complicated bower setup)?
Just want to make sure the bower approach makes sense in the long-term (or will some developer 10 years from now wonder what the .bowerrc file is doing in codebase ).
MD Support makes a very good point above which has been demonstrated well in the project. For jquery, especially, new versions come with new shiny features(especially when bringing in other javascript packages that require more modern jquery versions). If we force the developer whom wants a to bring in that new shiny feature into the codebase to also test the new version of jquery on the entire codebase and fix everything, then that new shiny feature would never get into the codebase (thus stifling innovation over the long term).
My thoughts are that we would bring in all new assets into the new assets directory (via bower or however the community decides) for now. Agree that migrating the older assets is very low priority and can be migrated over further down the road and agree it would make good tasks for developers new to the project.
One more point on this. Once we do get all the assets organized in a way that makes it clear which versions are being used, we could then take on the onerous task of removing the old versions and upgrading the scripts that are using them to use the new versions. This would then lead us to a place where the codebase was all using the same version of the packages.
And at that point we will have numerous selenium tests that are testing every facet of OpenEMR
Thus could then try to enforce using only 1 version after above is completed.
Hi Robert,
I agree we have to separate locations of client side resources and server side resources.
I understand I’m late to the show, but please can I propose to use library/ folder ?
If we compare amount of static files ( JS, CSS, images ) in library/ and interface/ folders, then library/ already contains approx 800 such files , and interface/ contains ~600 . This would make library/ a clear winner
Yes I agree with this method, Using more than 1 version of any package is a recipe for disaster. (and one thing that always annoyed me about oemr) We should defnitley follow the standard that is currently around. or something similar?
“public/vendor”
This may even mean a bit of movement with the directory structure. Creating a new “Public” folder that holds all the assets and the entry index.php. Renaming some folders to a more “modernised php standard”.
: