Proposal for ES6 development on the staff client
As part of my work on bug 15522 <https://bugs.koha-community. org/bugzilla3/show_bug.cgi?id=15522>, I've been working with Preact (a React clone with a friendlier license). We've established that this needs ES6[1] in previous discussions on the mailing list and in IRC. From there, we found IE's many limitations meant we needed a transpiler[2] to to make use of these features. Owen and I have been thinking about the easiest way to do this, and this is the lowest-friction process we've come up with to transpile ES6: $ sudo apt-get install nodejs npm $ sudo npm install -g yarn $ yarn install $ yarn build Yarn is a somewhat faster version of npm, the de-facto JavaScript package manager. Normally, this would be a pointless addition, but the npm in the Debian repositories is 3 major versions out of date, and therefore not a great option. Many npm packages simply fail to install. This is a constant problem with the JS packages in the Debian repos; most if not all of the tools that one might want either are completely unpackaged or woefully out of date. Packaging them ourselves means working our way through a number of dependencies (see [3] for an example). Any frontend build process worth our time cannot solely use packages from the upstream repos. That aside, this build process will use Gulp, Browserify and Babel to take any files in koha-tmpl/intranet-tmpl/prog/js/src, and compile them into a matching file in koha-tmpl/intranet-tmpl/prog/js/built . This means that any new files will not have to be manually whitelisted. You can see a working example at https://github.com/pianohacker/koha, branch bz15522. I'm currently committing the built versions of the files, but this is purely for convenience of prototyping. The page in question is admin/policy.pl, and the relevant code is at .../prog/js/src/admin/policy.js . [1] ECMAScript 6, a semi-recent version of JavaScript with a large number of new features, including a nice class syntax, arrow functions, and destructuring assignment. [2] A tool that transforms ES6 syntax (and the JSX syntax extension used by (P)react) into something that can be run by older browsers, including IE. [3] https://wiki.debian.org/Javascript/Nodejs/Tasks/gulp -- Jesse Weaver
Thanks for the info, Jesse. I haven’t reviewed Bugzilla or Github, but I just have a couple of questions. If I understand correctly, we’ll be bundling the Javascript packages in with Koha for deployment, is that right? If that’s the case, will only the build machine will need Nodejs, npm, yarn, Gulp, Browserify, Babel, etc? If so, then the onus of these additional dependencies is really just for developers or people installing from source? The Debian packages would just the transpiled versions of the Javascript? I imagine that would satisfy the community’s desire to just use upstream packages from Debian? For those of us who do install from source, would this transpiling process be automated via the Makefile? David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 From: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] On Behalf Of Jesse Sent: Wednesday, 30 August 2017 7:27 AM To: koha-devel@lists.koha-community.org Subject: [Koha-devel] Proposal for ES6 development on the staff client As part of my work on bug 15522 <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15522>, I've been working with Preact (a React clone with a friendlier license). We've established that this needs ES6[1] in previous discussions on the mailing list and in IRC. From there, we found IE's many limitations meant we needed a transpiler[2] to to make use of these features. Owen and I have been thinking about the easiest way to do this, and this is the lowest-friction process we've come up with to transpile ES6: $ sudo apt-get install nodejs npm $ sudo npm install -g yarn $ yarn install $ yarn build Yarn is a somewhat faster version of npm, the de-facto JavaScript package manager. Normally, this would be a pointless addition, but the npm in the Debian repositories is 3 major versions out of date, and therefore not a great option. Many npm packages simply fail to install. This is a constant problem with the JS packages in the Debian repos; most if not all of the tools that one might want either are completely unpackaged or woefully out of date. Packaging them ourselves means working our way through a number of dependencies (see [3] for an example). Any frontend build process worth our time cannot solely use packages from the upstream repos. That aside, this build process will use Gulp, Browserify and Babel to take any files in koha-tmpl/intranet-tmpl/prog/js/src, and compile them into a matching file in koha-tmpl/intranet-tmpl/prog/js/built . This means that any new files will not have to be manually whitelisted. You can see a working example at https://github.com/pianohacker/koha, branch bz15522. I'm currently committing the built versions of the files, but this is purely for convenience of prototyping. The page in question is admin/policy.pl <http://policy.pl> , and the relevant code is at .../prog/js/src/admin/policy.js . [1] ECMAScript 6, a semi-recent version of JavaScript with a large number of new features, including a nice class syntax, arrow functions, and destructuring assignment. [2] A tool that transforms ES6 syntax (and the JSX syntax extension used by (P)react) into something that can be run by older browsers, including IE. [3] https://wiki.debian.org/Javascript/Nodejs/Tasks/gulp -- Jesse Weaver
2017-08-29 17:33 GMT-06:00 David Cook <dcook@prosentient.com.au>:
Thanks for the info, Jesse. I haven’t reviewed Bugzilla or Github, but I just have a couple of questions.
If I understand correctly, we’ll be bundling the Javascript packages in with Koha for deployment, is that right?
Correct. After being built, all of the necessary JS (our own transpiled code and its dependencies) will be bundled together.
If that’s the case, will only the build machine will need Nodejs, npm, yarn, Gulp, Browserify, Babel, etc? If so, then the onus of these additional dependencies is really just for developers or people installing from source? The Debian packages would just the transpiled versions of the Javascript? I imagine that would satisfy the community’s desire to just use upstream packages from Debian?
Correct.
For those of us who do install from source, would this transpiling process be automated via the Makefile?
It easily could be. In my original email, the global install (sudo npm install -g) of yarn was purely for convenience. The entire process could become: $ sudo apt install nodejs npm # or koha-builddeps or koha-jsdeps (or koha-perldeps if we feel like being lazy) $ make build-js Where the Makefile took care of downloading yarn, installing all the JS dependencies, and building the files.
David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia
Office: 02 9212 0899
Direct: 02 8005 0595
*From:* koha-devel-bounces@lists.koha-community.org [mailto: koha-devel-bounces@lists.koha-community.org] *On Behalf Of *Jesse *Sent:* Wednesday, 30 August 2017 7:27 AM *To:* koha-devel@lists.koha-community.org *Subject:* [Koha-devel] Proposal for ES6 development on the staff client
As part of my work on bug 15522 <https://bugs.koha-community. org/bugzilla3/show_bug.cgi?id=15522>, I've been working with Preact (a React clone with a friendlier license). We've established that this needs ES6[1] in previous discussions on the mailing list and in IRC. From there, we found IE's many limitations meant we needed a transpiler[2] to to make use of these features.
Owen and I have been thinking about the easiest way to do this, and this is the lowest-friction process we've come up with to transpile ES6:
$ sudo apt-get install nodejs npm
$ sudo npm install -g yarn
$ yarn install
$ yarn build
Yarn is a somewhat faster version of npm, the de-facto JavaScript package manager. Normally, this would be a pointless addition, but the npm in the Debian repositories is 3 major versions out of date, and therefore not a great option. Many npm packages simply fail to install.
This is a constant problem with the JS packages in the Debian repos; most if not all of the tools that one might want either are completely unpackaged or woefully out of date. Packaging them ourselves means working our way through a number of dependencies (see [3] for an example). Any frontend build process worth our time cannot solely use packages from the upstream repos.
That aside, this build process will use Gulp, Browserify and Babel to take any files in koha-tmpl/intranet-tmpl/prog/js/src, and compile them into a matching file in koha-tmpl/intranet-tmpl/prog/js/built . This means that any new files will not have to be manually whitelisted.
You can see a working example at https://github.com/pianohacker/koha, branch bz15522. I'm currently committing the built versions of the files, but this is purely for convenience of prototyping. The page in question is admin/policy.pl, and the relevant code is at .../prog/js/src/admin/policy.js .
[1] ECMAScript 6, a semi-recent version of JavaScript with a large number of new features, including a nice class syntax, arrow functions, and destructuring assignment.
[2] A tool that transforms ES6 syntax (and the JSX syntax extension used by (P)react) into something that can be run by older browsers, including IE. [3] https://wiki.debian.org/Javascript/Nodejs/Tasks/gulp
--
Jesse Weaver
-- Jesse Weaver
If we are bundling the resulting Js, it means when we commit we include the resulting Js. The Makefile itself doesn't need to run those tasks. On mar., 29 de ago. de 2017 8:50 PM Jesse <pianohacker@gmail.com> wrote:
2017-08-29 17:33 GMT-06:00 David Cook <dcook@prosentient.com.au>:
Thanks for the info, Jesse. I haven’t reviewed Bugzilla or Github, but I just have a couple of questions.
If I understand correctly, we’ll be bundling the Javascript packages in with Koha for deployment, is that right?
Correct. After being built, all of the necessary JS (our own transpiled code and its dependencies) will be bundled together.
If that’s the case, will only the build machine will need Nodejs, npm, yarn, Gulp, Browserify, Babel, etc? If so, then the onus of these additional dependencies is really just for developers or people installing from source? The Debian packages would just the transpiled versions of the Javascript? I imagine that would satisfy the community’s desire to just use upstream packages from Debian?
Correct.
For those of us who do install from source, would this transpiling process be automated via the Makefile?
It easily could be. In my original email, the global install (sudo npm install -g) of yarn was purely for convenience. The entire process could become:
$ sudo apt install nodejs npm # or koha-builddeps or koha-jsdeps (or koha-perldeps if we feel like being lazy) $ make build-js
Where the Makefile took care of downloading yarn, installing all the JS dependencies, and building the files.
David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia
Office: 02 9212 0899
Direct: 02 8005 0595
*From:* koha-devel-bounces@lists.koha-community.org [mailto: koha-devel-bounces@lists.koha-community.org] *On Behalf Of *Jesse *Sent:* Wednesday, 30 August 2017 7:27 AM *To:* koha-devel@lists.koha-community.org *Subject:* [Koha-devel] Proposal for ES6 development on the staff client
As part of my work on bug 15522 < https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15522>, I've been working with Preact (a React clone with a friendlier license). We've established that this needs ES6[1] in previous discussions on the mailing list and in IRC. From there, we found IE's many limitations meant we needed a transpiler[2] to to make use of these features.
Owen and I have been thinking about the easiest way to do this, and this is the lowest-friction process we've come up with to transpile ES6:
$ sudo apt-get install nodejs npm
$ sudo npm install -g yarn
$ yarn install
$ yarn build
Yarn is a somewhat faster version of npm, the de-facto JavaScript package manager. Normally, this would be a pointless addition, but the npm in the Debian repositories is 3 major versions out of date, and therefore not a great option. Many npm packages simply fail to install.
This is a constant problem with the JS packages in the Debian repos; most if not all of the tools that one might want either are completely unpackaged or woefully out of date. Packaging them ourselves means working our way through a number of dependencies (see [3] for an example). Any frontend build process worth our time cannot solely use packages from the upstream repos.
That aside, this build process will use Gulp, Browserify and Babel to take any files in koha-tmpl/intranet-tmpl/prog/js/src, and compile them into a matching file in koha-tmpl/intranet-tmpl/prog/js/built . This means that any new files will not have to be manually whitelisted.
You can see a working example at https://github.com/pianohacker/koha, branch bz15522. I'm currently committing the built versions of the files, but this is purely for convenience of prototyping. The page in question is admin/policy.pl, and the relevant code is at .../prog/js/src/admin/policy.js .
[1] ECMAScript 6, a semi-recent version of JavaScript with a large number of new features, including a nice class syntax, arrow functions, and destructuring assignment.
[2] A tool that transforms ES6 syntax (and the JSX syntax extension used by (P)react) into something that can be run by older browsers, including IE. [3] https://wiki.debian.org/Javascript/Nodejs/Tasks/gulp
--
Jesse Weaver
-- Jesse Weaver _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
-- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 GPG: B2F3C15F
In that case, the onus would be on the original committer to build once and commit it as a bundle to Koha. I suppose that makes sense. I wonder if there’s any advantage to providing the sources and having people build it themselves. You’d have to do that for server-side code, but I can’t imagine there would be any repercussions in this case since it’s client-side code? David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 From: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] On Behalf Of Tomas Cohen Arazi Sent: Monday, 11 September 2017 10:21 PM Cc: koha-devel <koha-devel@lists.koha-community.org> Subject: Re: [Koha-devel] Proposal for ES6 development on the staff client If we are bundling the resulting Js, it means when we commit we include the resulting Js. The Makefile itself doesn't need to run those tasks. On mar., 29 de ago. de 2017 8:50 PM Jesse <pianohacker@gmail.com <mailto:pianohacker@gmail.com> > wrote: 2017-08-29 17:33 GMT-06:00 David Cook <dcook@prosentient.com.au <mailto:dcook@prosentient.com.au> >: Thanks for the info, Jesse. I haven’t reviewed Bugzilla or Github, but I just have a couple of questions. If I understand correctly, we’ll be bundling the Javascript packages in with Koha for deployment, is that right? Correct. After being built, all of the necessary JS (our own transpiled code and its dependencies) will be bundled together. If that’s the case, will only the build machine will need Nodejs, npm, yarn, Gulp, Browserify, Babel, etc? If so, then the onus of these additional dependencies is really just for developers or people installing from source? The Debian packages would just the transpiled versions of the Javascript? I imagine that would satisfy the community’s desire to just use upstream packages from Debian? Correct. For those of us who do install from source, would this transpiling process be automated via the Makefile? It easily could be. In my original email, the global install (sudo npm install -g) of yarn was purely for convenience. The entire process could become: $ sudo apt install nodejs npm # or koha-builddeps or koha-jsdeps (or koha-perldeps if we feel like being lazy) $ make build-js Where the Makefile took care of downloading yarn, installing all the JS dependencies, and building the files. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 From: koha-devel-bounces@lists.koha-community.org <mailto:koha-devel-bounces@lists.koha-community.org> [mailto:koha-devel-bounces@lists.koha-community.org <mailto:koha-devel-bounces@lists.koha-community.org> ] On Behalf Of Jesse Sent: Wednesday, 30 August 2017 7:27 AM To: koha-devel@lists.koha-community.org <mailto:koha-devel@lists.koha-community.org> Subject: [Koha-devel] Proposal for ES6 development on the staff client As part of my work on bug 15522 <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15522>, I've been working with Preact (a React clone with a friendlier license). We've established that this needs ES6[1] in previous discussions on the mailing list and in IRC. From there, we found IE's many limitations meant we needed a transpiler[2] to to make use of these features. Owen and I have been thinking about the easiest way to do this, and this is the lowest-friction process we've come up with to transpile ES6: $ sudo apt-get install nodejs npm $ sudo npm install -g yarn $ yarn install $ yarn build Yarn is a somewhat faster version of npm, the de-facto JavaScript package manager. Normally, this would be a pointless addition, but the npm in the Debian repositories is 3 major versions out of date, and therefore not a great option. Many npm packages simply fail to install. This is a constant problem with the JS packages in the Debian repos; most if not all of the tools that one might want either are completely unpackaged or woefully out of date. Packaging them ourselves means working our way through a number of dependencies (see [3] for an example). Any frontend build process worth our time cannot solely use packages from the upstream repos. That aside, this build process will use Gulp, Browserify and Babel to take any files in koha-tmpl/intranet-tmpl/prog/js/src, and compile them into a matching file in koha-tmpl/intranet-tmpl/prog/js/built . This means that any new files will not have to be manually whitelisted. You can see a working example at https://github.com/pianohacker/koha, branch bz15522. I'm currently committing the built versions of the files, but this is purely for convenience of prototyping. The page in question is admin/policy.pl <http://policy.pl> , and the relevant code is at .../prog/js/src/admin/policy.js . [1] ECMAScript 6, a semi-recent version of JavaScript with a large number of new features, including a nice class syntax, arrow functions, and destructuring assignment. [2] A tool that transforms ES6 syntax (and the JSX syntax extension used by (P)react) into something that can be run by older browsers, including IE. [3] https://wiki.debian.org/Javascript/Nodejs/Tasks/gulp -- Jesse Weaver -- Jesse Weaver _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ -- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/> ) ✆ +54 9351 3513384 GPG: B2F3C15F
I expect you would also have to ship the client source code for dev installs, and to meet license requirements. I could be wrong though. On Mon, Sep 11, 2017 at 5:32 PM, David Cook <dcook@prosentient.com.au> wrote:
In that case, the onus would be on the original committer to build once and commit it as a bundle to Koha. I suppose that makes sense. I wonder if there’s any advantage to providing the sources and having people build it themselves. You’d have to do that for server-side code, but I can’t imagine there would be any repercussions in this case since it’s client-side code?
David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia
Office: 02 9212 0899
Direct: 02 8005 0595
*From:* koha-devel-bounces@lists.koha-community.org [mailto: koha-devel-bounces@lists.koha-community.org] *On Behalf Of *Tomas Cohen Arazi *Sent:* Monday, 11 September 2017 10:21 PM *Cc:* koha-devel <koha-devel@lists.koha-community.org> *Subject:* Re: [Koha-devel] Proposal for ES6 development on the staff client
If we are bundling the resulting Js, it means when we commit we include the resulting Js. The Makefile itself doesn't need to run those tasks.
On mar., 29 de ago. de 2017 8:50 PM Jesse <pianohacker@gmail.com> wrote:
2017-08-29 17:33 GMT-06:00 David Cook <dcook@prosentient.com.au>:
Thanks for the info, Jesse. I haven’t reviewed Bugzilla or Github, but I just have a couple of questions.
If I understand correctly, we’ll be bundling the Javascript packages in with Koha for deployment, is that right?
Correct. After being built, all of the necessary JS (our own transpiled code and its dependencies) will be bundled together.
If that’s the case, will only the build machine will need Nodejs, npm, yarn, Gulp, Browserify, Babel, etc? If so, then the onus of these additional dependencies is really just for developers or people installing from source? The Debian packages would just the transpiled versions of the Javascript? I imagine that would satisfy the community’s desire to just use upstream packages from Debian?
Correct.
For those of us who do install from source, would this transpiling process be automated via the Makefile?
It easily could be. In my original email, the global install (sudo npm install -g) of yarn was purely for convenience. The entire process could become:
$ sudo apt install nodejs npm # or koha-builddeps or koha-jsdeps (or koha-perldeps if we feel like being lazy)
$ make build-js
Where the Makefile took care of downloading yarn, installing all the JS dependencies, and building the files.
David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia
Office: 02 9212 0899
Direct: 02 8005 0595
*From:* koha-devel-bounces@lists.koha-community.org [mailto: koha-devel-bounces@lists.koha-community.org] *On Behalf Of *Jesse *Sent:* Wednesday, 30 August 2017 7:27 AM *To:* koha-devel@lists.koha-community.org *Subject:* [Koha-devel] Proposal for ES6 development on the staff client
As part of my work on bug 15522 <https://bugs.koha-community. org/bugzilla3/show_bug.cgi?id=15522>, I've been working with Preact (a React clone with a friendlier license). We've established that this needs ES6[1] in previous discussions on the mailing list and in IRC. From there, we found IE's many limitations meant we needed a transpiler[2] to to make use of these features.
Owen and I have been thinking about the easiest way to do this, and this is the lowest-friction process we've come up with to transpile ES6:
$ sudo apt-get install nodejs npm
$ sudo npm install -g yarn
$ yarn install
$ yarn build
Yarn is a somewhat faster version of npm, the de-facto JavaScript package manager. Normally, this would be a pointless addition, but the npm in the Debian repositories is 3 major versions out of date, and therefore not a great option. Many npm packages simply fail to install.
This is a constant problem with the JS packages in the Debian repos; most if not all of the tools that one might want either are completely unpackaged or woefully out of date. Packaging them ourselves means working our way through a number of dependencies (see [3] for an example). Any frontend build process worth our time cannot solely use packages from the upstream repos.
That aside, this build process will use Gulp, Browserify and Babel to take any files in koha-tmpl/intranet-tmpl/prog/js/src, and compile them into a matching file in koha-tmpl/intranet-tmpl/prog/js/built . This means that any new files will not have to be manually whitelisted.
You can see a working example at https://github.com/pianohacker/koha, branch bz15522. I'm currently committing the built versions of the files, but this is purely for convenience of prototyping. The page in question is admin/policy.pl, and the relevant code is at .../prog/js/src/admin/policy.js .
[1] ECMAScript 6, a semi-recent version of JavaScript with a large number of new features, including a nice class syntax, arrow functions, and destructuring assignment.
[2] A tool that transforms ES6 syntax (and the JSX syntax extension used by (P)react) into something that can be run by older browsers, including IE. [3] https://wiki.debian.org/Javascript/Nodejs/Tasks/gulp
--
Jesse Weaver
--
Jesse Weaver
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
--
Tomás Cohen Arazi
Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 <+54%209%20351%20351-3384> GPG: B2F3C15F
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
-- Michael Hafen Washington County School District Technology Department Systems Analyst
I don’t think you’d need to for dev installs, but maybe you would for license requirements. I could see that. Should definitely look into that. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 From: Michael Hafen [mailto:michael.hafen@washk12.org] Sent: Wednesday, 13 September 2017 1:51 AM To: David Cook <dcook@prosentient.com.au> Cc: Tomas Cohen Arazi <tomascohen@gmail.com>; koha-devel <koha-devel@lists.koha-community.org> Subject: Re: [Koha-devel] Proposal for ES6 development on the staff client I expect you would also have to ship the client source code for dev installs, and to meet license requirements. I could be wrong though. On Mon, Sep 11, 2017 at 5:32 PM, David Cook <dcook@prosentient.com.au <mailto:dcook@prosentient.com.au> > wrote: In that case, the onus would be on the original committer to build once and commit it as a bundle to Koha. I suppose that makes sense. I wonder if there’s any advantage to providing the sources and having people build it themselves. You’d have to do that for server-side code, but I can’t imagine there would be any repercussions in this case since it’s client-side code? David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 From: koha-devel-bounces@lists.koha-community.org <mailto:koha-devel-bounces@lists.koha-community.org> [mailto:koha-devel-bounces@lists.koha-community.org <mailto:koha-devel-bounces@lists.koha-community.org> ] On Behalf Of Tomas Cohen Arazi Sent: Monday, 11 September 2017 10:21 PM Cc: koha-devel <koha-devel@lists.koha-community.org <mailto:koha-devel@lists.koha-community.org> > Subject: Re: [Koha-devel] Proposal for ES6 development on the staff client If we are bundling the resulting Js, it means when we commit we include the resulting Js. The Makefile itself doesn't need to run those tasks. On mar., 29 de ago. de 2017 8:50 PM Jesse <pianohacker@gmail.com <mailto:pianohacker@gmail.com> > wrote: 2017-08-29 17:33 GMT-06:00 David Cook <dcook@prosentient.com.au <mailto:dcook@prosentient.com.au> >: Thanks for the info, Jesse. I haven’t reviewed Bugzilla or Github, but I just have a couple of questions. If I understand correctly, we’ll be bundling the Javascript packages in with Koha for deployment, is that right? Correct. After being built, all of the necessary JS (our own transpiled code and its dependencies) will be bundled together. If that’s the case, will only the build machine will need Nodejs, npm, yarn, Gulp, Browserify, Babel, etc? If so, then the onus of these additional dependencies is really just for developers or people installing from source? The Debian packages would just the transpiled versions of the Javascript? I imagine that would satisfy the community’s desire to just use upstream packages from Debian? Correct. For those of us who do install from source, would this transpiling process be automated via the Makefile? It easily could be. In my original email, the global install (sudo npm install -g) of yarn was purely for convenience. The entire process could become: $ sudo apt install nodejs npm # or koha-builddeps or koha-jsdeps (or koha-perldeps if we feel like being lazy) $ make build-js Where the Makefile took care of downloading yarn, installing all the JS dependencies, and building the files. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 From: koha-devel-bounces@lists.koha-community.org <mailto:koha-devel-bounces@lists.koha-community.org> [mailto:koha-devel-bounces@lists.koha-community.org <mailto:koha-devel-bounces@lists.koha-community.org> ] On Behalf Of Jesse Sent: Wednesday, 30 August 2017 7:27 AM To: koha-devel@lists.koha-community.org <mailto:koha-devel@lists.koha-community.org> Subject: [Koha-devel] Proposal for ES6 development on the staff client As part of my work on bug 15522 <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15522>, I've been working with Preact (a React clone with a friendlier license). We've established that this needs ES6[1] in previous discussions on the mailing list and in IRC. From there, we found IE's many limitations meant we needed a transpiler[2] to to make use of these features. Owen and I have been thinking about the easiest way to do this, and this is the lowest-friction process we've come up with to transpile ES6: $ sudo apt-get install nodejs npm $ sudo npm install -g yarn $ yarn install $ yarn build Yarn is a somewhat faster version of npm, the de-facto JavaScript package manager. Normally, this would be a pointless addition, but the npm in the Debian repositories is 3 major versions out of date, and therefore not a great option. Many npm packages simply fail to install. This is a constant problem with the JS packages in the Debian repos; most if not all of the tools that one might want either are completely unpackaged or woefully out of date. Packaging them ourselves means working our way through a number of dependencies (see [3] for an example). Any frontend build process worth our time cannot solely use packages from the upstream repos. That aside, this build process will use Gulp, Browserify and Babel to take any files in koha-tmpl/intranet-tmpl/prog/js/src, and compile them into a matching file in koha-tmpl/intranet-tmpl/prog/js/built . This means that any new files will not have to be manually whitelisted. You can see a working example at https://github.com/pianohacker/koha, branch bz15522. I'm currently committing the built versions of the files, but this is purely for convenience of prototyping. The page in question is admin/policy.pl <http://policy.pl> , and the relevant code is at .../prog/js/src/admin/policy.js . [1] ECMAScript 6, a semi-recent version of JavaScript with a large number of new features, including a nice class syntax, arrow functions, and destructuring assignment. [2] A tool that transforms ES6 syntax (and the JSX syntax extension used by (P)react) into something that can be run by older browsers, including IE. [3] https://wiki.debian.org/Javascript/Nodejs/Tasks/gulp -- Jesse Weaver -- Jesse Weaver _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ -- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/> ) ✆ +54 9351 3513384 <tel:+54%209%20351%20351-3384> GPG: B2F3C15F _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ -- Michael Hafen Washington County School District Technology Department Systems Analyst
The point of dev installs is for devs to be able to work on the code in a pseudo installed state. Being able to modify and recompile these JS files would be part of that I think. On Tue, Sep 12, 2017 at 5:11 PM, David Cook <dcook@prosentient.com.au> wrote:
I don’t think you’d need to for dev installs, but maybe you would for license requirements. I could see that. Should definitely look into that.
David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St <https://maps.google.com/?q=72/330+Wattle+St+Ultimo,+NSW+2007+Australia+%C2%A0+Office:+02&entry=gmail&source=g>
Ultimo, NSW 2007 <https://maps.google.com/?q=72/330+Wattle+St+Ultimo,+NSW+2007+Australia+%C2%A0+Office:+02&entry=gmail&source=g>
Office: 02 <https://maps.google.com/?q=72/330+Wattle+St+Ultimo,+NSW+2007+Australia+%C2%A0+Office:+02&entry=gmail&source=g> 9212 0899
Direct: 02 8005 0595
*From:* Michael Hafen [mailto:michael.hafen@washk12.org] *Sent:* Wednesday, 13 September 2017 1:51 AM *To:* David Cook <dcook@prosentient.com.au> *Cc:* Tomas Cohen Arazi <tomascohen@gmail.com>; koha-devel < koha-devel@lists.koha-community.org>
*Subject:* Re: [Koha-devel] Proposal for ES6 development on the staff client
I expect you would also have to ship the client source code for dev installs, and to meet license requirements. I could be wrong though.
On Mon, Sep 11, 2017 at 5:32 PM, David Cook <dcook@prosentient.com.au> wrote:
In that case, the onus would be on the original committer to build once and commit it as a bundle to Koha. I suppose that makes sense. I wonder if there’s any advantage to providing the sources and having people build it themselves. You’d have to do that for server-side code, but I can’t imagine there would be any repercussions in this case since it’s client-side code?
David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St <https://maps.google.com/?q=72/330+Wattle+St+Ultimo,+NSW+2007+Australia+%C2%A0+Office:+02&entry=gmail&source=g>
Ultimo, NSW 2007 <https://maps.google.com/?q=72/330+Wattle+St+Ultimo,+NSW+2007+Australia+%C2%A0+Office:+02&entry=gmail&source=g>
Office: 02 <https://maps.google.com/?q=72/330+Wattle+St+Ultimo,+NSW+2007+Australia+%C2%A0+Office:+02&entry=gmail&source=g> 9212 0899
Direct: 02 8005 0595
*From:* koha-devel-bounces@lists.koha-community.org [mailto: koha-devel-bounces@lists.koha-community.org] *On Behalf Of *Tomas Cohen Arazi *Sent:* Monday, 11 September 2017 10:21 PM *Cc:* koha-devel <koha-devel@lists.koha-community.org> *Subject:* Re: [Koha-devel] Proposal for ES6 development on the staff client
If we are bundling the resulting Js, it means when we commit we include the resulting Js. The Makefile itself doesn't need to run those tasks.
On mar., 29 de ago. de 2017 8:50 PM Jesse <pianohacker@gmail.com> wrote:
2017-08-29 17:33 GMT-06:00 David Cook <dcook@prosentient.com.au>:
Thanks for the info, Jesse. I haven’t reviewed Bugzilla or Github, but I just have a couple of questions.
If I understand correctly, we’ll be bundling the Javascript packages in with Koha for deployment, is that right?
Correct. After being built, all of the necessary JS (our own transpiled code and its dependencies) will be bundled together.
If that’s the case, will only the build machine will need Nodejs, npm, yarn, Gulp, Browserify, Babel, etc? If so, then the onus of these additional dependencies is really just for developers or people installing from source? The Debian packages would just the transpiled versions of the Javascript? I imagine that would satisfy the community’s desire to just use upstream packages from Debian?
Correct.
For those of us who do install from source, would this transpiling process be automated via the Makefile?
It easily could be. In my original email, the global install (sudo npm install -g) of yarn was purely for convenience. The entire process could become:
$ sudo apt install nodejs npm # or koha-builddeps or koha-jsdeps (or koha-perldeps if we feel like being lazy)
$ make build-js
Where the Makefile took care of downloading yarn, installing all the JS dependencies, and building the files.
David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St <https://maps.google.com/?q=72/330+Wattle+St+Ultimo,+NSW+2007+Australia+%C2%A0+Office:+02&entry=gmail&source=g>
Ultimo, NSW 2007 <https://maps.google.com/?q=72/330+Wattle+St+Ultimo,+NSW+2007+Australia+%C2%A0+Office:+02&entry=gmail&source=g>
Office: 02 <https://maps.google.com/?q=72/330+Wattle+St+Ultimo,+NSW+2007+Australia+%C2%A0+Office:+02&entry=gmail&source=g> 9212 0899
Direct: 02 8005 0595
*From:* koha-devel-bounces@lists.koha-community.org [mailto: koha-devel-bounces@lists.koha-community.org] *On Behalf Of *Jesse *Sent:* Wednesday, 30 August 2017 7:27 AM *To:* koha-devel@lists.koha-community.org *Subject:* [Koha-devel] Proposal for ES6 development on the staff client
As part of my work on bug 15522 <https://bugs.koha-community. org/bugzilla3/show_bug.cgi?id=15522>, I've been working with Preact (a React clone with a friendlier license). We've established that this needs ES6[1] in previous discussions on the mailing list and in IRC. From there, we found IE's many limitations meant we needed a transpiler[2] to to make use of these features.
Owen and I have been thinking about the easiest way to do this, and this is the lowest-friction process we've come up with to transpile ES6:
$ sudo apt-get install nodejs npm
$ sudo npm install -g yarn
$ yarn install
$ yarn build
Yarn is a somewhat faster version of npm, the de-facto JavaScript package manager. Normally, this would be a pointless addition, but the npm in the Debian repositories is 3 major versions out of date, and therefore not a great option. Many npm packages simply fail to install.
This is a constant problem with the JS packages in the Debian repos; most if not all of the tools that one might want either are completely unpackaged or woefully out of date. Packaging them ourselves means working our way through a number of dependencies (see [3] for an example). Any frontend build process worth our time cannot solely use packages from the upstream repos.
That aside, this build process will use Gulp, Browserify and Babel to take any files in koha-tmpl/intranet-tmpl/prog/js/src, and compile them into a matching file in koha-tmpl/intranet-tmpl/prog/js/built . This means that any new files will not have to be manually whitelisted.
You can see a working example at https://github.com/pianohacker/koha, branch bz15522. I'm currently committing the built versions of the files, but this is purely for convenience of prototyping. The page in question is admin/policy.pl, and the relevant code is at .../prog/js/src/admin/policy.js .
[1] ECMAScript 6, a semi-recent version of JavaScript with a large number of new features, including a nice class syntax, arrow functions, and destructuring assignment.
[2] A tool that transforms ES6 syntax (and the JSX syntax extension used by (P)react) into something that can be run by older browsers, including IE. [3] https://wiki.debian.org/Javascript/Nodejs/Tasks/gulp
--
Jesse Weaver
--
Jesse Weaver
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
--
Tomás Cohen Arazi
Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 <+54%209%20351%20351-3384> GPG: B2F3C15F
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
--
Michael Hafen
Washington County School District Technology Department
Systems Analyst
-- Michael Hafen Washington County School District Technology Department Systems Analyst
participants (4)
-
David Cook -
Jesse -
Michael Hafen -
Tomas Cohen Arazi