IRC logs for #farmOS, 2021-06-18 (GMT)

[00:50:48]* ahmetartu[m] has joined #farmos
[01:07:20]* ahmetartu[m] is now known as artu[m]
[10:36:20]<symbioquine[m]><mstenta[m] "so for contrib modules that need"> As a module vendor, that would be a non-starter IMHO. As far as I'm concerned, modules should take at most two steps to install; 1) `composer require x/z` 2) `drush en z` (Plus possible subsequent UI configuration away from sensible/functional defaults.)
[10:36:54]<mstenta[m]>i agree
[10:37:02]<mstenta[m]>but if you're including a library now it will already require three steps
[10:37:18]<mstenta[m]>(i think?)
[10:37:36]<symbioquine[m]>Not necessarily...
[10:37:39]<mstenta[m]>(unless of course you package the library itself in your module directly)
[10:39:09]<mstenta[m]>true... so in that case you're bundling the JS dependencies in your packaged JS
[10:39:25]<mstenta[m]>and maybe for contrib that's just the best way to go
[10:39:55]<mstenta[m]>I think paul121 's point about adding additional libs for use in core is still a good consideration... eg: a charting library
[10:39:58]<symbioquine[m]>It seems like it - then you can use Webpack to minimize/tree-shake/etc
[10:40:34]<mstenta[m]>unless of course we decide to adopt a webpack step in our own build/packaging process...
[10:40:53]<symbioquine[m]>With Drupal's per-page aggregation, I don't think clients would get caching benefits from having the library's JS as a stand-alone file.
[10:41:18]<symbioquine[m]>So the main benefit I think I see is that the library would be versioned directly in the composer.json file...
[10:42:36]<symbioquine[m]>but, my understanding is that Composer isn't (and shouldn't be) a full-featured JS dependency manager, so things like managing locks on transitive JS dependencies will be harder.
[10:42:55]<mstenta[m]>> unless of course we decide to adopt a webpack step in our own build/packaging process...
[10:42:55]<mstenta[m]>paul121 maybe we should consider this again...
[10:43:10]<mstenta[m]>i think the main reason against it is supporting shared hosting environments that can't run npm
[10:43:28]<mstenta[m]>but... if we ran it as part of our packaging script then it would be built into our tarballs
[10:43:36]<mstenta[m]>which means shared hosting could at least use the tagged releases
[10:43:50]<mstenta[m]>if you were hosting a non-tagged release, you would have to install npm perhaps
[10:44:17]<mstenta[m]>(we should create a dedicated issue for this - i am probably forgetting some other considerations)
[10:45:57]<symbioquine[m]><mstenta[m] "but... if we ran it as part of o"> Or publish an NPM package that models the library dependencies and copies built versions into its "dist/" directory, then use Composer to include *that* package.
[10:46:44]<symbioquine[m]>Named something like ``
[10:46:55]<mstenta[m]>that's an interesting idea
[10:48:19]<symbioquine[m]>Or maybe `` if it includes any first-party built code...
[10:52:09]<symbioquine[m]><symbioquine[m] "Either of 8 or 9 am PST sound go"> This is probably my fault for leaving it at "either A or B" :) paul121 `et al` Do you want to meet in 10 minutes or in 70 minutes?
[10:53:37]<mstenta[m]>ah i'll have to miss it :-( let me know how it goes! :-)
[10:53:48]<mstenta[m]>gotta run... let's make an issue to think about the JS stuff soon!
[10:54:38]<paul121[m]>Could we do 70 min?
[10:54:48]<symbioquine[m]>Sounds good