Would it be possible to make @stork/cli on npm as an alternative installation method?

[jasikpark]

I'd really like to work on a workflow for integrating stork with https://github.com/snowpackjs/astro Astro sites, but it'd be best if we didn't have to require people to install rust to use the tool, especially since a JS API for triggering an index build would make integrating it into a post-processing script easier.

[jameslittle230]

@jasikpark - yes, probably!

I'm not sure what that would entail, but I can look into it. I totally agree that having more accessible installation options would be beneficial for everyone.

Thanks for writing in!
James

[jasikpark]

I imagine hopefully rustwasm publishing could be helpful? I'm hoping to be able to call an API from javascript that I can pass a list of files, or a stream of data to build an index..

Idk what problems you might run into trying to compile the cli as a npm package, though the cloudflare workers cli has recently started supporting npm install, so that might be another place to look at for inspiration!

[aFuzzyBear]

Hi @jameslittle230, I just wanted to say hi, after spending a couple of days looking over stork I must say, this is a very awesome wee package, unfortunately I'm not at all familiar with rust nor the underlying witchcraft used to make this wee package, but I would like to learn.

Coming back to Astro, I'm with @jasikpark, if there was a way to interact JS with the underpinnings of stork, we could possibly use it as part of a search facility for Astro users.

There was a couple of things that comes to mind, first of:

• Data Attributes, I understand that these act as placeholders for stork to pick up, I was wondering if stork could be adapted to pick up other data-attributes ie: data-stork to be data-search
• npm build directive, I was going to toy with setting up the build using node's child process and see if I got any joy with that, (ill report back if I do). Im thinking if we could have a build directive that could be added to the package.json that if the user has the search component on their site, they just need to add the directive and it should as a postbuild once Astro has done its ting.
• Allow for configuration of stork, I was thinking could this be added to the astro.config.mjs or should there be a search.toml file, but what if (like me) users have never written a toml file in their puff... could this be extended to incorporate other formats such as JSON or straight up JS? only for the configuration file. This way they can state what part of the site Stork should be reading and indexing, and not touch the witchcraft underneath

Thanks for making this wee package man, I must confess, its really cool. and thanks @jasikpark for getting the ball rolling on this, very much excited to bring this to life =)

[jasikpark]

I would say that we would probably want to make it so we could have an Astro plugin that integrates with the Collections API somehow + automatically calls stork from within the plugin after the site is done building, rather than being in the package.json?

[jameslittle230]

Hi, sorry it's so much later, but I'm cleaning up issues now. Three things:

1. I'm going to close this issue in favor of Publish Stork UI package to NPM #129, since they're both describing the same sort of thing. I've added a nice long comment in 129 describing my intentions for making Stork an NPM package.
2. That said, "Stork should accept JSON as an input format" is also a good idea, and I'll make that its own issue so it can be tracked separately. (edit: Stork should accept JSON as an input format #198)
3. @aFuzzyBear - I'd love some more details about what problem you're describing with the data-stork attribute -- I don't quite understand today. If possible (and if you remember, sorry it's so much later), could you open a new discussion to help me understand what you're trying to do, and then if a feature/bug comes out of that I'll add it here?

Appreciate your patience.