Introduce the use of Grunt or Gulp?
I would very much like to start using some kind of build tool for front-end assets in Koha. The ones I've encountered are Grunt and Gulp: Grunt: http://gruntjs.com/ Gulp: http://gulpjs.com/ I have some experience with Grunt, and have heard good things about Gulp. Has anyone else used either in their non-Koha projects? Adopting them would introduce a little more complexity to the process of making client-side changes to Koha, and to be honest I'm not sure of the right way to incorporate the tools into our workflow. What I see as the advantages: - Automatic linting, minification, and concatenation of CSS and JS - Potentially, automatic compression of images and contruction of image sprites - Overall performance improvements from the above Disadvantages: A new process to learn for those wanting to contribute front-end modifications. A new set of dependencies for front-end developers (Node.js etc). If there is interest I'd be happy to submit a patch introducing the process to the OPAC as a demonstration. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
I really like this idea; it would help some longstanding performance issues on the OPAC (and perhaps, eventually, the staff side). Even better, it would make regeneration of the CSS from the LESS a bit more straightforward, and allow us to remove the generated files from Git. Eventually, it could also give a cleaner solution for some of the caching issues we've hacked around. It seems like the easiest way forward would be to minify/concatenate all of the JS and CSS that is shown on every page (so we could just throw a link to the output in doc-head-close). Thoughts? 2016-02-07 18:53 GMT-07:00 Owen Leonard <oleonard@myacpl.org>:
I would very much like to start using some kind of build tool for front-end assets in Koha. The ones I've encountered are Grunt and Gulp:
Grunt: http://gruntjs.com/ Gulp: http://gulpjs.com/
I have some experience with Grunt, and have heard good things about Gulp. Has anyone else used either in their non-Koha projects?
Adopting them would introduce a little more complexity to the process of making client-side changes to Koha, and to be honest I'm not sure of the right way to incorporate the tools into our workflow.
What I see as the advantages:
- Automatic linting, minification, and concatenation of CSS and JS - Potentially, automatic compression of images and contruction of image sprites - Overall performance improvements from the above
Disadvantages: A new process to learn for those wanting to contribute front-end modifications. A new set of dependencies for front-end developers (Node.js etc).
If there is interest I'd be happy to submit a patch introducing the process to the OPAC as a demonstration.
-- Owen
-- Web Developer Athens County Public Libraries http://www.myacpl.org _______________________________________________ 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/
-- Jesse Weaver
make regeneration of the CSS from the LESS a bit more straightforward, and allow us to remove the generated files from Git.
Removing the generated files from git makes sense from a front-end developer's point of view, but I wonder if that doesn't create too many problems for packaging/installation, as well as complicate things for developers who don't want to mess with generating those files when they're not touching the interface? That's something I was hoping to prompt some discussion on. Any votes for Gulp over Grunt, or something else entirely? -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
Hi, On Tue, Feb 9, 2016 at 5:57 PM, Owen Leonard <oleonard@myacpl.org> wrote:
Removing the generated files from git makes sense from a front-end developer's point of view, but I wonder if that doesn't create too many problems for packaging/installation
As far as *packaging* is concerned... I'd just as soon that no generated files be retained in Git, and that we rely on the build mechanism to generate them.
as well as complicate things for developers who don't want to mess with generating those files when they're not touching the interface?
The tricky part is ongoing updates, although Jake (and Grunt and Gulp) do have the ability to set up "watch tasks", meaning that it's probably possible to set something up so that recompiling/reuglify-ing can happen automatically. Of course, some additional developer documentation would need to be written. Regards, Galen -- Galen Charlton Infrastructure and Added Services Manager Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
Hi, On Sun, Feb 7, 2016 at 8:53 PM, Owen Leonard <oleonard@myacpl.org> wrote:
I have some experience with Grunt, and have heard good things about Gulp. Has anyone else used either in their non-Koha projects?
Grunt is used by Evergreen's new web staff interface; while I can't claim to be an expert in it, it gets the job done.
Adopting them would introduce a little more complexity to the process of making client-side changes to Koha, and to be honest I'm not sure of the right way to incorporate the tools into our workflow.
From a packaging point of view... I ended up down a rabbit hole. Grunt itself is not packaged for Debian due to a long-standing issues with one of its own devDependencies, JSHint [1]. I don't see any signs that Gulp is packaged either.
Using Grunt would therefore present a problem: it would require a build dependency that is not itself packaged for Debian. I note that Debian's package of jQuery includes a custom build script to avoid using Grunt. Jake [2] *is* packaged for Debian -- would that work for you as an alternative, Owen?
If there is interest I'd be happy to submit a patch introducing the process to the OPAC as a demonstration.
+1 for doing something, but see above. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673727 [2] https://github.com/jakejs/jake Regards, Galen -- Galen Charlton Infrastructure and Added Services Manager Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
Jake [2] *is* packaged for Debian -- would that work for you as an alternative, Owen?
After a quick look at Jake I'm concerned that it is not as fully-featured or well-documented than Grunt or Gulp. The wider adoption of Grunt and Gulp mean that there is a more vibrant array of plugins for each and discussion on the web to provide help and documentation. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
Hi! I'm working on 3.22.02 and my logs are FILLED with the following warnings: Members.pm: Unable to load Koha::*NorwegianPatronDB* at /blurred/C4/Members.pm line 46., referer: http://blurred/cgi-bin/koha/acqui/booksellers.pl admin-home.pl: Unable to load Koha::*NorwegianPatronDB* at /blurred/C4/Members.pm line 46., referer: http://blurred/cgi-bin/koha/admin/preferences.pl I look at the code, and beside wondering why that custom feature is so profoundly imbricated into master Koha, I was wondering what is not working. So I hacked the code to add verbose => 1 on the can_load call, and found that NorwegianPatronDB was not compiling because it was missing the following libraries: apt-get -y install libsoap-lite-perl apt-get -y install libcrypt-gcrypt-perl apt-get -y install libconvert-basen-perl Those modules are specified as NOT mandatory in 3.22. As such, I should not be flooded with Norwegian errors because they are not available, for a module which I and most do not care for. Or am I getting it wrong? Thanks Philippe
I think you're right, Philippe. I've noticed the same thing. In fact, the "Unable to load Koha::NorwegianPatronDB" was added after the fact to stop the absence of those libraries causing Koha to die. I don't necessarily see the point of having that warning there though, as most Koha users probably aren't going to use the NorwegianPatronDB. Maybe that could have a system preference. so the warns (or the dying) only happens when the system preference is set? David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 From: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] On Behalf Of Philippe Blouin Sent: Thursday, 11 February 2016 8:47 AM To: koha-devel@lists.koha-community.org Subject: [Koha-devel] NorwegianPatronDB Hi! I'm working on 3.22.02 and my logs are FILLED with the following warnings: Members.pm: Unable to load Koha::NorwegianPatronDB at /blurred/C4/Members.pm line 46., referer: http://blurred/cgi-bin/koha/acqui/booksellers.pl admin-home.pl: Unable to load Koha::NorwegianPatronDB at /blurred/C4/Members.pm line 46., referer: http://blurred/cgi-bin/koha/admin/preferences.pl I look at the code, and beside wondering why that custom feature is so profoundly imbricated into master Koha, I was wondering what is not working. So I hacked the code to add verbose => 1 on the can_load call, and found that NorwegianPatronDB was not compiling because it was missing the following libraries: apt-get -y install libsoap-lite-perl apt-get -y install libcrypt-gcrypt-perl apt-get -y install libconvert-basen-perl Those modules are specified as NOT mandatory in 3.22. As such, I should not be flooded with Norwegian errors because they are not available, for a module which I and most do not care for. Or am I getting it wrong? Thanks Philippe
Greetings, It seems that “$debug && warn” is a popular style used in C4/Member already. I don’t think a system preference is needed. Just a $debug prepend, perhaps? https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15795 Sign it off, kill it, suggest a counter-patch, whatever. I do think this addresses the issue. GPML, Mark Tompsett From: David Cook Sent: Wednesday, February 10, 2016 6:40 PM To: 'Philippe Blouin' Cc: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] NorwegianPatronDB I think you’re right, Philippe. I’ve noticed the same thing. In fact, the “Unable to load Koha::NorwegianPatronDB” was added after the fact to stop the absence of those libraries causing Koha to die. I don’t necessarily see the point of having that warning there though, as most Koha users probably aren’t going to use the NorwegianPatronDB. Maybe that could have a system preference… so the warns (or the dying) only happens when the system preference is set? David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 From: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] On Behalf Of Philippe Blouin Sent: Thursday, 11 February 2016 8:47 AM To: koha-devel@lists.koha-community.org Subject: [Koha-devel] NorwegianPatronDB Hi! I'm working on 3.22.02 and my logs are FILLED with the following warnings: Members.pm: Unable to load Koha::NorwegianPatronDB at /blurred/C4/Members.pm line 46., referer: http://blurred/cgi-bin/koha/acqui/booksellers.pl admin-home.pl: Unable to load Koha::NorwegianPatronDB at /blurred/C4/Members.pm line 46., referer: http://blurred/cgi-bin/koha/admin/preferences.pl I look at the code, and beside wondering why that custom feature is so profoundly imbricated into master Koha, I was wondering what is not working. So I hacked the code to add verbose => 1 on the can_load call, and found that NorwegianPatronDB was not compiling because it was missing the following libraries: apt-get -y install libsoap-lite-perl apt-get -y install libcrypt-gcrypt-perl apt-get -y install libconvert-basen-perl Those modules are specified as NOT mandatory in 3.22. As such, I should not be flooded with Norwegian errors because they are not available, for a module which I and most do not care for. Or am I getting it wrong? Thanks Philippe -------------------------------------------------------------------------------- _______________________________________________ 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/
Apparently libsoap-lite-perl, libcrypt-gcrypt-perl and libconvert-basen-perl should be/remain mandatory in 3.22, as they are required by a non-optional module, even if the functionality it provides is not used. 2016-02-11 5:06 GMT+02:00 Mark Tompsett <mtompset@hotmail.com>:
Greetings,
It seems that “$debug && warn” is a popular style used in C4/Member already. I don’t think a system preference is needed. Just a $debug prepend, perhaps?
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15795 Sign it off, kill it, suggest a counter-patch, whatever. I do think this addresses the issue.
GPML, Mark Tompsett
*From:* David Cook <dcook@prosentient.com.au> *Sent:* Wednesday, February 10, 2016 6:40 PM *To:* 'Philippe Blouin' <philippe.blouin@inlibro.com> *Cc:* koha-devel@lists.koha-community.org *Subject:* Re: [Koha-devel] NorwegianPatronDB
I think you’re right, Philippe.
I’ve noticed the same thing. In fact, the “Unable to load Koha::NorwegianPatronDB” was added after the fact to stop the absence of those libraries causing Koha to die.
I don’t necessarily see the point of having that warning there though, as most Koha users probably aren’t going to use the NorwegianPatronDB.
Maybe that could have a system preference… so the warns (or the dying) only happens when the system preference is set?
David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St, Ultimo, NSW 2007
*From:* koha-devel-bounces@lists.koha-community.org [mailto: koha-devel-bounces@lists.koha-community.org] *On Behalf Of *Philippe Blouin *Sent:* Thursday, 11 February 2016 8:47 AM *To:* koha-devel@lists.koha-community.org *Subject:* [Koha-devel] NorwegianPatronDB
Hi! I'm working on 3.22.02 and my logs are FILLED with the following warnings:
Members.pm: Unable to load Koha::*NorwegianPatronDB* at /blurred/C4/Members.pm line 46., referer: http://blurred/cgi-bin/koha/acqui/booksellers.pl admin-home.pl: Unable to load Koha::*NorwegianPatronDB* at /blurred/C4/Members.pm line 46., referer: http://blurred/cgi-bin/koha/admin/preferences.pl
I look at the code, and beside wondering why that custom feature is so profoundly imbricated into master Koha, I was wondering what is not working.
So I hacked the code to add verbose => 1 on the can_load call, and found that NorwegianPatronDB was not compiling because it was missing the following libraries:
apt-get -y install libsoap-lite-perl apt-get -y install libcrypt-gcrypt-perl apt-get -y install libconvert-basen-perl
Those modules are specified as NOT mandatory in 3.22. As such, I should not be flooded with Norwegian errors because they are not available, for a module which I and most do not care for.
Or am I getting it wrong?
Thanks Philippe
------------------------------ _______________________________________________ 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/
_______________________________________________ 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/
I think we should ship with all the dependencies. We cannot make people's Koha break if they enable some feature. 2016-02-11 17:47 GMT-03:00 Manos PETRIDIS <egpetridis@gmail.com>:
Apparently libsoap-lite-perl, libcrypt-gcrypt-perl and libconvert-basen-perl should be/remain mandatory in 3.22, as they are required by a non-optional module, even if the functionality it provides is not used.
2016-02-11 5:06 GMT+02:00 Mark Tompsett <mtompset@hotmail.com>:
Greetings,
It seems that “$debug && warn” is a popular style used in C4/Member already. I don’t think a system preference is needed. Just a $debug prepend, perhaps?
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15795 Sign it off, kill it, suggest a counter-patch, whatever. I do think this addresses the issue.
GPML, Mark Tompsett
*From:* David Cook <dcook@prosentient.com.au> *Sent:* Wednesday, February 10, 2016 6:40 PM *To:* 'Philippe Blouin' <philippe.blouin@inlibro.com> *Cc:* koha-devel@lists.koha-community.org *Subject:* Re: [Koha-devel] NorwegianPatronDB
I think you’re right, Philippe.
I’ve noticed the same thing. In fact, the “Unable to load Koha::NorwegianPatronDB” was added after the fact to stop the absence of those libraries causing Koha to die.
I don’t necessarily see the point of having that warning there though, as most Koha users probably aren’t going to use the NorwegianPatronDB.
Maybe that could have a system preference… so the warns (or the dying) only happens when the system preference is set?
David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St, Ultimo, NSW 2007
*From:* koha-devel-bounces@lists.koha-community.org [mailto: koha-devel-bounces@lists.koha-community.org] *On Behalf Of *Philippe Blouin *Sent:* Thursday, 11 February 2016 8:47 AM *To:* koha-devel@lists.koha-community.org *Subject:* [Koha-devel] NorwegianPatronDB
Hi! I'm working on 3.22.02 and my logs are FILLED with the following warnings:
Members.pm: Unable to load Koha::*NorwegianPatronDB* at /blurred/C4/Members.pm line 46., referer: http://blurred/cgi-bin/koha/acqui/booksellers.pl admin-home.pl: Unable to load Koha::*NorwegianPatronDB* at /blurred/C4/Members.pm line 46., referer: http://blurred/cgi-bin/koha/admin/preferences.pl
I look at the code, and beside wondering why that custom feature is so profoundly imbricated into master Koha, I was wondering what is not working.
So I hacked the code to add verbose => 1 on the can_load call, and found that NorwegianPatronDB was not compiling because it was missing the following libraries:
apt-get -y install libsoap-lite-perl apt-get -y install libcrypt-gcrypt-perl apt-get -y install libconvert-basen-perl
Those modules are specified as NOT mandatory in 3.22. As such, I should not be flooded with Norwegian errors because they are not available, for a module which I and most do not care for.
Or am I getting it wrong?
Thanks Philippe
------------------------------ _______________________________________________ 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/
_______________________________________________ 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/
_______________________________________________ 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 (http://theke.io) ✆ +54 9351 3513384 GPG: B2F3C15F
FYI, if you’re using the Crypt::GCrypt module from CPAN (ie you’re not using a Debian-based system with libcrypt-gcrypt-perl), Koha is probably going to be unable to load Koha::NorwegianPatronDB. The CPAN module has issues which the Debian team have patched, and the CPAN author appears to have zero interest in patching the CPAN version (or talking about it at all). I wonder what CPAN’s policy is on abandoned modules… My point is that if you’re not using the Debian package, you’re that Crypt::GCrypt dependency appears to always fail now. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 From: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] On Behalf Of Tomas Cohen Arazi Sent: Saturday, 13 February 2016 2:52 AM To: Manos PETRIDIS <egpetridis@gmail.com> Cc: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] NorwegianPatronDB I think we should ship with all the dependencies. We cannot make people's Koha break if they enable some feature. 2016-02-11 17:47 GMT-03:00 Manos PETRIDIS <egpetridis@gmail.com <mailto:egpetridis@gmail.com> >: Apparently libsoap-lite-perl, libcrypt-gcrypt-perl and libconvert-basen-perl should be/remain mandatory in 3.22, as they are required by a non-optional module, even if the functionality it provides is not used. 2016-02-11 5:06 GMT+02:00 Mark Tompsett <mtompset@hotmail.com <mailto:mtompset@hotmail.com> >: Greetings, It seems that “$debug && warn” is a popular style used in C4/Member already. I don’t think a system preference is needed. Just a $debug prepend, perhaps? https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15795 Sign it off, kill it, suggest a counter-patch, whatever. I do think this addresses the issue. GPML, Mark Tompsett From: David Cook <mailto:dcook@prosentient.com.au> Sent: Wednesday, February 10, 2016 6:40 PM To: 'Philippe Blouin' <mailto:philippe.blouin@inlibro.com> Cc: koha-devel@lists.koha-community.org <mailto:koha-devel@lists.koha-community.org> Subject: Re: [Koha-devel] NorwegianPatronDB I think you’re right, Philippe. I’ve noticed the same thing. In fact, the “Unable to load Koha::NorwegianPatronDB” was added after the fact to stop the absence of those libraries causing Koha to die. I don’t necessarily see the point of having that warning there though, as most Koha users probably aren’t going to use the NorwegianPatronDB. Maybe that could have a system preference… so the warns (or the dying) only happens when the system preference is set? David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 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 Philippe Blouin Sent: Thursday, 11 February 2016 8:47 AM To: koha-devel@lists.koha-community.org <mailto:koha-devel@lists.koha-community.org> Subject: [Koha-devel] NorwegianPatronDB Hi! I'm working on 3.22.02 and my logs are FILLED with the following warnings: Members.pm: Unable to load Koha::NorwegianPatronDB at /blurred/C4/Members.pm line 46., referer: http://blurred/cgi-bin/koha/acqui/booksellers.pl admin-home.pl <http://admin-home.pl> : Unable to load Koha::NorwegianPatronDB at /blurred/C4/Members.pm line 46., referer: http://blurred/cgi-bin/koha/admin/preferences.pl I look at the code, and beside wondering why that custom feature is so profoundly imbricated into master Koha, I was wondering what is not working. So I hacked the code to add verbose => 1 on the can_load call, and found that NorwegianPatronDB was not compiling because it was missing the following libraries: apt-get -y install libsoap-lite-perl apt-get -y install libcrypt-gcrypt-perl apt-get -y install libconvert-basen-perl Those modules are specified as NOT mandatory in 3.22. As such, I should not be flooded with Norwegian errors because they are not available, for a module which I and most do not care for. Or am I getting it wrong? Thanks Philippe _____ _______________________________________________ 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/ _______________________________________________ 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/ _______________________________________________ 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 (http://theke.io <http://theke.io/> ) ✆ +54 9351 3513384 GPG: B2F3C15F
Hi, On Wed, Feb 10, 2016 at 9:35 AM, Owen Leonard <oleonard@myacpl.org> wrote:
After a quick look at Jake I'm concerned that it is not as fully-featured or well-documented than Grunt or Gulp.
I agree, although for the specific purpose of compiling LESS, minifying Javascript (and doing that dynamically for the purpose of a dev setup), at first blush Jake looks like it might be sufficient.
The wider adoption of Grunt and Gulp mean that there is a more vibrant array of plugins for each and discussion on the web to provide help and documentation.
Agreed — unfortunately, that has not (yet) translated into there being Debian packages for them. That said, there is a work-around that Debian packagers have used for projects like jQuery: writing a custom build script strictly for use by packaging and production installations from tarball that requires only uglifyjs and packaged Node.js modules. I might be willing to write such a thing, and it could complement use of Grunt or Gulp for folks actively contributing to front-end development. Regards, Galen -- Galen Charlton Infrastructure and Added Services Manager Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
I agree, although for the specific purpose of compiling LESS, minifying Javascript (and doing that dynamically for the purpose of a dev setup), at first blush Jake looks like it might be sufficient.
As an example, here is the range of tasks covered by an introduction to Gulp (https://markgoodyear.com/2014/01/getting-started-with-gulp/): Sass compile (gulp-ruby-sass) Autoprefixer (gulp-autoprefixer) Minify CSS (gulp-cssnano) JSHint (gulp-jshint) Concatenation (gulp-concat) Uglify (gulp-uglify) Compress images (gulp-imagemin) LiveReload (gulp-livereload) Caching of images so only changed images are compressed (gulp-cache) Notify of changes (gulp-notify) Clean files for a clean build (del) (And yes I will also push for us to convert to Sass). -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
Am I missing something in the ' need for it to be packaged ' here? aren't they Dev tools, to be used in a development type install during development? Then used in the build stage for producing packages. I'd suggest keeping the resultant files in git for the current build scripts to use for production builds for instance, and lean on the qa script to ensure they were created using the grunt processing. That way only a frontend Dev need install grunt/gulp to use. I would say keeping the grunt file in git is a good idea though. My two pence On 11 Feb 2016 1:24 pm, "Owen Leonard" <oleonard@myacpl.org> wrote:
I agree, although for the specific purpose of compiling LESS, minifying Javascript (and doing that dynamically for the purpose of a dev setup), at first blush Jake looks like it might be sufficient.
As an example, here is the range of tasks covered by an introduction to Gulp (https://markgoodyear.com/2014/01/getting-started-with-gulp/):
Sass compile (gulp-ruby-sass) Autoprefixer (gulp-autoprefixer) Minify CSS (gulp-cssnano) JSHint (gulp-jshint) Concatenation (gulp-concat) Uglify (gulp-uglify) Compress images (gulp-imagemin) LiveReload (gulp-livereload) Caching of images so only changed images are compressed (gulp-cache) Notify of changes (gulp-notify) Clean files for a clean build (del)
(And yes I will also push for us to convert to Sass).
-- Owen
-- Web Developer Athens County Public Libraries http://www.myacpl.org _______________________________________________ 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/
Hi, On Thu, Feb 11, 2016 at 2:01 PM, Renvoize, Martin <martin.renvoize@ptfs-europe.com> wrote:
Am I missing something in the ' need for it to be packaged ' here? aren't they Dev tools, to be used in a development type install during development?
Then used in the build stage for producing packages.
Well, using them in the build stage is exactly the sticking point -- it would be preferable to not be dependent on build tools that aren't themselves packaged for Debian. To be clear, however, that isn't an argument against folks using Grunt or Gulp to assist with front-end development so long as what's directly needed for packaging and production installs (such as minification and LESS compilation) can be accomplished without requiring non-packaged tools (and as I mentioned before, I'm willing to help with that).
I'd suggest keeping the resultant files in git for the current build scripts to use for production builds for instance, and lean on the qa script to ensure they were created using the grunt processing.
I'm not in favor of this as a long-term solution, but I recognize that continuing to do this (as we already do for the Bootstrap LESS files) may be a work-around. Regards, Galen -- Galen Charlton Infrastructure and Added Services Manager Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
On Thu, Feb 11, 2016 at 2:57 PM, Galen Charlton <gmc@esilibrary.com> wrote:
Well, using them in the build stage is exactly the sticking point -- it would be preferable to not be dependent on build tools that aren't themselves packaged for Debian.
Is that to avoid requiring that release manager build compiled versions of files for each release?
so long as what's directly needed for packaging and production installs (such as minification and LESS compilation) can be accomplished without requiring non-packaged tools
I don't see a role for a build tool which can't be used to build production files. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
Are we at an impasse on this? I think the lack of *something* to manage front-end assets is making Koha less efficient to use and more difficult and error-prone to develop for. -- Owen
One workaround for the Gulp/Grunt/DFSG issue would be to build a Debian package and host it on the koha-community repo. I would be willing to do this. Unfortunately, all of the frontend build tools seem to either: a) have license issues preventing them from having an official Debian package (Grunt, Gulp), b) not be popular enough to have a package or be viable (broccoli, others) or c) have limitations in functionality that make them not worth the effort (Jake). I agree with Owen both that this is strongly needed and that it would be doing complex enough tasks to make maintaining a separate, limited build script for packaging/tarball installs untenable. 2016-02-26 14:10 GMT-07:00 Owen Leonard <oleonard@myacpl.org>:
Are we at an impasse on this? I think the lack of *something* to manage front-end assets is making Koha less efficient to use and more difficult and error-prone to develop for.
-- Owen _______________________________________________ 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/
-- Jesse Weaver
On 26 February 2016 at 22:10, Owen Leonard <oleonard@myacpl.org> wrote:
Are we at an impasse on this? I think the lack of *something* to manage front-end assets is making Koha less efficient to use and more difficult and error-prone to develop for.
how about using webpack? https://webpack.github.io/docs/ -Wolfram -- Wolfram Schneider <wosch@FreeBSD.org> http://wolfram.schneider.org
On Wed, Mar 2, 2016 at 11:44 AM, Wolfram Schneider <wosch@freebsd.org> wrote:
how about using webpack?
Kyle proposes the use of webpack in his React proof of concept (Bug 17297 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17297). Since then I've been investigating and learning it and it looks like it might be a good solution for us. Here at the Hackfest in Marseille we had a discussion about React. I don't think I can say that we came to a final decision, but I think we are strongly leaning in the direction of going forward with it. The decision we did make was that we would go ahead and introduce a build process for front-end assets--probably with webpack. I'm going to work on a patch to demonstrate the workflow, probably one which begins with some simple minification tasks. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
YAY! El mié., 12 oct. 2016 a las 12:41, Owen Leonard (<oleonard@myacpl.org>) escribió:
On Wed, Mar 2, 2016 at 11:44 AM, Wolfram Schneider <wosch@freebsd.org> wrote:
how about using webpack?
Kyle proposes the use of webpack in his React proof of concept (Bug 17297 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17297). Since then I've been investigating and learning it and it looks like it might be a good solution for us.
Here at the Hackfest in Marseille we had a discussion about React. I don't think I can say that we came to a final decision, but I think we are strongly leaning in the direction of going forward with it.
The decision we did make was that we would go ahead and introduce a build process for front-end assets--probably with webpack. I'm going to work on a patch to demonstrate the workflow, probably one which begins with some simple minification tasks.
-- Owen
-- Web Developer Athens County Public Libraries http://www.myacpl.org _______________________________________________ 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
If Owen is happy with changes for the front-end, I'm happy :p. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595
-----Original Message----- From: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel- bounces@lists.koha-community.org] On Behalf Of Owen Leonard Sent: Wednesday, 12 October 2016 9:41 PM To: Koha Devel <koha-devel@lists.koha-community.org> Subject: Re: [Koha-devel] Introduce the use of Grunt or Gulp?
On Wed, Mar 2, 2016 at 11:44 AM, Wolfram Schneider <wosch@freebsd.org> wrote:
how about using webpack?
Kyle proposes the use of webpack in his React proof of concept (Bug 17297 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17297). Since then I've been investigating and learning it and it looks like it might be a good solution for us.
Here at the Hackfest in Marseille we had a discussion about React. I don't think I can say that we came to a final decision, but I think we are strongly leaning in the direction of going forward with it.
The decision we did make was that we would go ahead and introduce a build process for front-end assets--probably with webpack. I'm going to work on a patch to demonstrate the workflow, probably one which begins with some simple minification tasks.
-- Owen
-- Web Developer Athens County Public Libraries http://www.myacpl.org _______________________________________________ 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/
participants (10)
-
David Cook -
Galen Charlton -
Jesse -
Manos PETRIDIS -
Mark Tompsett -
Owen Leonard -
Philippe Blouin -
Renvoize, Martin -
Tomas Cohen Arazi -
Wolfram Schneider