Update external libraries, e.g. jQuery

[zuphilip]

Most of the libraries in external are date 4-5 years old and I am quite sure that most of them have newer version. It seems for me that especially the jQuery library should be updated because currently this will already give some warnings about deprecated code:

Use of getPreventDefault() is deprecated.  Use defaultPrevented instead.  require-jquery.js:5304:28

Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user’s experience. For more help http://xhr.spec.whatwg.org/  require-jquery.js:10221:6

It seems that jQuery was packed together with require and some more code in a special JavaScript file require-jquery.js some time ago: 5f06bd6

[rmzelle]

@zuphilip, it looks like that file came from the requirejs project, and it seems that the packed version was deprecated four years ago: http://requirejs.org/docs/jquery.html#oldexample and requirejs/requirejs@c072183#diff-0e4001b2ab34240aa60898bba3618dcdR50

[adam3smith]

I'm happy to try to help review&test PRs on this, but given my experience with updating js libraries and keeping the code working (i.e. stuff always breaks and it takes a lot of time), I don't think I'll have the time to do this.

[zuphilip]

I think this might be a larger issue and need more work or maybe even more experienced people. I don't think I will have time to look into this any time soon. However, there might be the danger, that at some time any of this deprecated things will break it completely.

Here is another example: One of the core library might also be jstree, where currently the pre 1.0 version is used, but at the moment there is version 3.3.3 out, i.e. the last 720 commits of this library is missing for the csl-editor.

[rmzelle]

I'm happy to try to help review&test PRs on this, but given my experience with updating js libraries and keeping the code working (i.e. stuff always breaks and it takes a lot of time), I don't think I'll have the time to do this.

Did you have to do anything special this time around to keep things working? You mentioned elsewhere that the citeproc-js library was giving troubles again.

[rmzelle]

(I'm still working up the courage to try out the build script)

[adam3smith]

I'd have to look, but we have some CSL money left, though I'm afraid I'm not too optimistic about us getting any more. All of our management-level contacts with Springer/Papers and Elsevier/Mendeley have dried up.

[adam3smith]

Did you have to do anything special this time around to keep things working?

This time around, citeproc-js threw an error: Juris-M/citeproc-js#28
Last time, I managed to align all libraries installed via npm to use up-to-date versions, so that's great.
Also, the configure.sh script just runs a long time, so that any errors that don't break it immediately are "costly" in terms of time.

[zuphilip]

Okay, I have now a developing environment with docker:

git clone --recursive https://github.com/citation-style-editor/csl-editor-demo-site.git csl-editor-demo-site
cd csl-editor-demo-site
docker run --rm -ti -p 5001:5001 -v `pwd`:/srv/jekyll jekyll/jekyll jekyll serve --watch

That was easier than expected. Maybe, I can look closer here...

[rmzelle]

@zuphilip, how will running it in Docker help you? (curious since I have no experience with Docker)

[zuphilip]

Most of the time I work under windows and don't have Jekyll (or Node.js) installed. Therefore, I can use now Docker to set up an development version and let the Docker image deal with all the prerequisites. The -v option will map my current directory into the Docker image, such that every change I make locally will also effect the Docker image (and vice versa) and because Jekyll is "watching" the source will be rebuild, such that when I look at the local website at http://localhost:5001 the changes are visible directly (or I can just rerun the tests).

There might be more direct ways without Docker to achieve the same. However, for me the Docker way is easy and clean way for running a "local server" for development. One general advantage is that the Docker containers are "encapsulate" and clean such that no other process or previous installation of something might lead to different solutions. Moreover, it is possible to use the same version with Docker also in production (can't judge here other aspects as security).

[rmzelle]

Cool. So how long do the builds take with your setup?

(also, do you have any recommended resources for those new to Docker? I tinker a little with Linux VMs at work for running some bioinformatics tools, and I have the impression that switching to Docker might be easier for me)

[zuphilip]

So how long do the builds take with your setup?

Technically I don't "build" the docker images but I just "run" one. So the first time the image will be actually downloaded from https://hub.docker.com/r/jekyll/jekyll/ (~ 50 MB) and the time depends on your internet connection. From now on starting/running this docker container takes just some seconds. Inside the docker container Jekyll starts and this take mabey up to a minute, but this time you always have.

My general impression is that Docker is fast and also not taking much resources, except that disk space is used easily with docker images and containers and maybe also older things one would not need any longer...

You can find my personal (chaotic) notes about Docker here https://hackmd.io/MbCsBMAZQFlBaAhgI3MeMBMBOc8AcOA7PJgIwTADMApjAGxn6hA=#

[rmzelle]

Technically I don't "build" the docker images but I just "run" one.

Ah, okay. So you just do "jekyll serve" as written at https://github.com/citation-style-language/csl-editor-demo-site#to-setup-development-version

I thought you were running deploy.sh within Docker as well, which is why I was asking about build times.

[adam3smith]

FWIW, deploy.sh is a tiny script that's almost instantaneous as it just copies some files and then runs gh commands on them. It's configure.sh in the csl-editor-library that runs a long time because it calculates all the example files.

…

On Wed, Jan 25, 2017 at 9:27 AM, Rintze M. Zelle ***@***.***> wrote: Technically I don't "build" the docker images but I just "run" one. Ah, okay. So you just do "jekyll serve" as written at https://github.com/citation-style-language/csl-editor-demo-site#to-setup- development-version I thought you were running deploy.sh within Docker as well, which is why I was asking about build times. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#204 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAH32k6EVS__wbWmdaprpcP8TCX8R3S-ks5rV1vlgaJpZM4LqVJA> .

-- Sebastian Karcher, PhD www.sebastiankarcher.com

[rmzelle]

Also, the configure.sh script just runs a long time, so that any errors that don't break it immediately are "costly" in terms of time.

FWIW, deploy.sh is a tiny script that's almost instantaneous as it just
copies some files and then runs gh commands on them. It's configure.sh in
the csl-editor-library that runs a long time because it calculates all the
example files.

Ah, okay. I didn't know what the exact purpose of deploy.sh was. Since we can run the test suite and editor itself straight via Jekyll, we only really need the deploy.sh for regenerating the examples for SearchByExample, and for pushing the results to GitHub Pages?