Make Trunk a library

[lucperkins]

I'm currently working on a CLI tool for documentation that, ideally, would be able to produce single-page apps out of a wide variety of inputs. In other words, I want this tool to have Trunk's functionality wrapped inside of it (alongside many other capabilities). In order to do so, however, Trunk would need to be made into an importable dependency, which it currently isn't. I think this would be fairly easy to do and I'm volunteering to do the work. But I wanted to make sure that this wouldn't run contrary to the project's core goals. If this sounds like a reasonable change, let me know and I'll submit a PR; otherwise, I'll likely maintain a personal fork and depend on that for my CLI tool.

[thedodd]

@lucperkins thanks for opening this issue. I'll need to think about this a bit. A few quick thoughts:

• we already have plans to publish a Trunk library as described here: https://github.com/thedodd/trunk/issues/9
  • the main idea with this lib is to allow for integration between Rust source code (irrespective of any frameworks being used) with the trunk CLI (including images/assets via direct source code reference).
• what you are requesting seems to be different. You seem to be looking for the core Trunk pipeline & build system to be exposed as a library.

That being the case, here are my questions:

1. Trunk can be summarized as a system which produces a dist dir with a WASM webapp ready to be served over a network. If that is exactly what you need, then why not just install the trunk CLI and issue a subprocess call to invoke Trunk CLI? Tokio (and other runtimes) expose async interop with subprocess calls.
2. If you are looking for something other than that end to end functionality, do you mind enumerating what those requirements are? I'm imagining that you probably don't want the watch, serve or clean functionality (corresponding to the CLI's subcommands bearing the same names).

Lastly, maybe you can provide some pseudo code of what you think this interface should look like.

[lucperkins]

@thedodd So, this past weekend I did go through and "library"-ize the Trunk CLI. Just in case it's useful (probably not!) here's how I did it:

https://github.com/lucperkins/trunk/commit/4710851d851a429080e0ec926187b3cc4b6544d0 https://github.com/lucperkins/trunk/commit/a4b56d843a46cbe9dd5c40741be5ccdb4206699a https://github.com/lucperkins/trunk/commit/201c73104b2b578e45b6b188b0517d6095a1f223 https://github.com/lucperkins/trunk/commit/ee72d6f57354869497d7292441fca405665a8540

Unfortunately, that didn't quite get me what I need. Which is not at all to criticize the lovely Trunk, there are just different goals in play and what I'm trying to build doesn't quite fit with the Trunk model. Basically, I want to build a CLI that can turn documentation into a single-page app. So you point the tool at a big directory full of docs and get a Wasm-powered SPA. There will be built-in themes (Sass, JS, etc.) that you could select, plus some fun components (written in Rust!), search indexing, and all of that good stuff. There are currently tools that can do this but they're all JavaScript (like Gatsby), with the attendant drawbacks. Trunk is of course fantastic for building the already-created Yew app into HTML/Wasm/etc. but this tool would also need to create that app out of other sources (Markdown, etc.) in the first place.

So it seems likely that I'll need to build more than I originally expected to but I imagine that that some Trunk and Yew internals may help me along quite a bit.

[thedodd]

Nice, I understand a bit better now. I'm not sure if you've seen this project: https://www.getzola.org/ it is built in Rust, but it still uses JS for various things ... but I wonder if this would be a better option as a starting point simply because Zola has components for static site templates, pulling in static markdown, so on and so forth. A bit more aligned with what you are saying. From there, perhaps generating some rust boilerplate to be compiled by Trunk would fit well.

Thoughts? Also, to be sure, I'm just sharing thoughts, I'm not trying to dismiss the possibility / use case of doing this with Trunk.

[lucperkins]

@thedodd Oh, I forgot to include this:

https://github.com/lucperkins/dock/blob/main/src/main.rs

I did get my CLI actually using Trunk. Pretty simple!

I have seen Zola, yes, but Zola is more of a traditional site generator, whereas I'm attempting to turn docs into single-page apps and to free users from having to think about templating at all (by having themes baked into the tool itself). So basically I'd be compiling many Markdown files (or other formats) into Yew components and using the Yew router to navigate.

[bacongobbler]

Hey @lucperkins! Is this project still available somewhere? Looks like lucperkins/dock returns a 404.

[lucperkins]

No, this is actually a discontinued project, I'm afraid! And not at all because of Trunk 😀 Basically what I was trying to build was a fancy static site generator that can turn various documentation sources (local Markdown, remote GraphQL objects, etc) into single-page apps, but with a single executable.

[futursolo]

I have created #606 as a MVP to separate trunk pipelines from trunk cli. If this approach looks good by maintainers, I will try to land this pull request by separating the content of it into multiple smaller pull requests.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 5 days with no activity.