IRC logs for #farmOS, 2023-01-29 (GMT)

2023-01-28
2023-01-30
TimeNickMessage
[04:55:22]<wotnak[m]>jgaehring Would it be possible to publish field-kit npm packages to npmjs.com so field-scripts could be used in custom/contrib modules to create field modules? Currently, it seems that they aren't published to any package registry, which practically limits creating new field modules to field-kit repo.
[05:19:10]<FarmerEd[m]>s/wen/when/, s/as/ask/
[08:22:03]<symbioquine[m]>wotnak: Are you talking about contrib field modules or supporting code for building field modules?
[08:34:46]<wotnak[m]>Supporting code for building field modules. For now, as a temporary workaround, I published the packages to my github package registry (https://github.com/wotnak?tab=packages&repo_name=field-kit), but it would be nice to just use the official ones.
[08:37:17]<symbioquine[m]>jgaehring would have to confirm, but I suspect that's just one of the bits that hasn't been prioritized yet for the Field Kit developer experience.
[08:37:37]<symbioquine[m]>s/Field/field/, s/Kit/module/
[08:39:47]<symbioquine[m]>I'd bet that's part of the "Comprehensive Dev Tooling" that **is not** planned/funded for the Field Kit Beta release: https://farmos.discourse.group/t/field-kit-status-update/1457
[09:49:31]<jgaehring[m]><wotnak[m]> "jgaehring Would it be possible..." <- I've been reluctant to make any specific promises about the dev tooling, as symbioquine noted, particularly on account of some of the third-party dependencies like [Mocha](https://github.com/farmOS/field-kit/issues/482) and [Storybook](https://github.com/farmOS/field-kit/issues/483); however, I'm far more optimistic I can include the internal tooling packages in the beta release that's
[09:49:31]<jgaehring[m]>forthcoming in the next couple weeks
[09:51:52]<jgaehring[m]>I actually wasn't aware anyone was already looking into field module development, but I'm psyched to see your interest, wotnak! I'm happy to accelerate the timeline for publishing those packages on the npm registry if it facilitates what you're working on (also super curious to know more about that!)
[09:53:09]<jgaehring[m]>I've already prepared and versioned the field-scripts for release, just didn't prioritize actual publication because I hadn't documented them yet, so it would be pretty easy
[09:54:57]<jgaehring[m]>only real issue is whether or not to scope them to the `@farmos.org` npm organization, which seems best, but I can't recall if I have the permissions to create a new package there (so might need to enlist mstenta on that count)
[09:57:57]<jgaehring[m]><jgaehring[m]> "I've been reluctant to make..." <- also, regarding more comprehensive tooling, I'm pretty confident I can whip together a quick `create-field-module` CLI tool for release, which should allow for quick and easy scaffolding of new field modules, already have a separate branch on my fork for this feature, and have a pretty well-developed sense of how to implement it:
[09:57:58]<jgaehring[m]>https://github.com/farmOS/field-kit/issues/422
[10:15:25]<wotnak[m]><jgaehring[m]> "I actually wasn't aware anyone..." <- As I mentioned earlier, I worked around the issue by publishing the packages to my scoped github package registry, so there's not really a need for acceleration on the account of what I'm doing.
[10:15:25]<wotnak[m]>I'm using the egg harvest quick form [updated](https://github.com/wotnak/farm_eggs) to farmOS v2, and want to create a field module with similar functionality for easier log recording right at the moment of gathering eggs instead of later at the computer.