Integrating npm front-end with Kallithea

[Dominik Ruf]

Mads Kiilerich <mads at kiilerich.com> schrieb am So., 12. Nov. 2017 um
21:39 Uhr:

> On 11/08/2017 03:05 PM, Andrew Shadura wrote:
> > On 8 November 2017 at 14:42, Mads Kiilerich <mads at kiilerich.com> wrote:
> >> On 11/08/2017 01:44 PM, Andrew Shadura wrote:
> >>> Well, I did submit a proof of concept using lesscpy two years ago, and
> >>> that went nowhere.
> >> Can you find a reference to it so we can re-evaluate?
> >
> https://lists.sfconservancy.org/pipermail/kallithea-general/2015q2/000788.html
>
> Thanks.
>
> Something like that could indeed be used to generate our current
> style.css, which is based on less since a couple of weeks ago.
>
> (Once conern, though: Compiling from less on runtime is great for
> development, but for actual installation of released versions, it should
> probably generate it earlier so it can be served as a static file from
> CDN (or heavily cached)).
>
> Could you or someone extend this proposaal to also cover the front-end
> build changes done in
>
> https://kallithea-scm.org/repos/kallithea/pull-request/108/_/bootstrap_in_small_bites_v7?fulldiff=1
> (and also handle jQuery and all the other front-end dependencies). (That
> would also require all dependency source to somehow be made available.)
>
> > I'm much less concerned about vendoring than about a huge dependency
> > on npm and its infrastructure.
>
> That is a good point.
>
> But without the dependency on npm and its infrastructure, *we* would
> have to provide an alternative huge dependency and infrastructure. That
> also doesn't sound appealing.
>
> If we don't depend on npm to provide source of our dependencies, then we
> have to provide them somehow.
>
> Then, some kind of automatic vendoring could seem appealing. It could
> perhaps be something that put the dependencies in release tar-balls
> without having to put their source in our source repository.
>
> "Vendoring" could perhaps also happen by automatically "caching" and
> shipping everything npm would download, thus allow npm to run entirely
> offline?
>
> >>> I don't understand what's so difficult about Lessing a bunch of files
> >>> and amalgamating them afterwards so that we absolutely have to use the
> >>> upstream's build system.
>
> That might be a crucial point. I think it might be prohibitively
> difficult to not use upstream build systems.
>
> Packages might do different things in their build system. It is not just
> about lessing a few files. I think it will be a significant amount of
> work and very fragile and make dependency version updates hard.
>
> > My concern about npm isn't only that it is a whole different
> > programming language, but that the infrastructure around npm is too
> > chaotic to be reasonable, there are too many indirect dependencies,
> > too many moving parts, things change a lot and too often. It's not
> > something I would like to base anything, to be honest.
>
> That might be true. But still, pragmatically, it pretty much works. It
> will allow us to move faster. Saying no to it will slow us down.
>
> > I think we definitely need to somehow vendor jQuery and other js
> > libraries, and — absolutely — Bootstrap. We need to be able to
> > reproducibly build it from the source, and npm not only doesn't make
> > that easier, but complicates that task and makes our build system more
> > fragile.
>
>
> Personally, I agree it could be nice if we compiled all front-end
> dependencies "directly from source" without using npm. But we don't
> "have" to do it if we don't ship compiled front-end code.
>
>
> Anyway, short term, what do you suggest we do so we can move forward
> with
>
> https://kallithea-scm.org/repos/kallithea/pull-request/108/_/bootstrap_in_small_bites_v7?fulldiff=1
> ?
>
> I suggest we temporarily move forward with this "easy" solution of
> building front-end using "plain" npm at install time.
>
> Meanwhile, others can work on distributing all dependency source and
> come up with a better solution than building with npm. (And perhaps
> also, perhaps as an intermediate step, make sure we offer all necessary
> sources so we can compile front-end code "offline" with npm and
> distribute it.
>
I don't like the npm dependency for pip installations either.
I think it'd be better to include the bootstrap source files and minified
files in the manifest.
That way, one can use any less (and minification) tool (even offline) and
we comply to the GPL.
This doesn't mean these source file should be in our mercurial repository.
(I strongly believe they should not.)
We (the developers) should add scripts/tools to the repository that make it
easy for us
to add and update 3rd-party less, css and js libraries.
In my view npm is the easiest tool for this.

More generally speaking we should distinguish between the 2 jobs node/npm
are doing.
1. be the run time for the less compiler
I think we should use node for this job because we should use the reference
implementation of less and that runs on node.
AFAIK lesscpy is not feature complete and there have been no commits to the
project in more then a year.
2. be the package manager for js/css/less libraries
I think for this task npm is the easiest/best solution as well.
Since (at least at the moment) we only depend on only a few libraries (and
only use npm
for bootstrap), I don't think we should expect much (if any) problems with
it.
And like Mads already mentioned, it is the most used tool for this and if
we decide to not use it, we still need to manage our css/less/js libraries
in some other way.


> /Mads
>
> _______________________________________________
> kallithea-general mailing list
> kallithea-general at sfconservancy.org
> https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sfconservancy.org/pipermail/kallithea-general/attachments/20171113/0968b470/attachment-0001.html>