| [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:38:16] | <symbioquine[m]> | https://github.com/symbioquine/farmOS_vue_page_demo |
| [10:39:09] | <mstenta[m]> | true... so in that case you're bundling the JS dependencies in your packaged JS |
| [10:39:14] | <symbioquine[m]> | yep |
| [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:44] | <mstenta[m]> | right |
| [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 `farmos.org/farmos-core-js-deps` |
| [10:46:51] | <mstenta[m]> | hmm |
| [10:46:55] | <mstenta[m]> | that's an interesting idea |
| [10:48:19] | <symbioquine[m]> | Or maybe `farmos.org/farmos-core-js` 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? https://meet.jit.si/farmos-dev? |
| [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 |