Starter template configuration is opaque

[johndunderhill]

You have buried the Rollup configuration in a script that also builds it up dynamically. I can no longer look in one place to see what my Rollup configuration is. I have to try to trace a complex function to figure out what configuration will result.

This is awful, and makes it very hard to integrate Routify into an existing project. Like many developers, I have other things going on in my build process and my bundler, and can’t blindly adopt your template. With the sparse documentation, I’m sunk.

Routify itself is magnificent. It’s the best Svelte router out there. But it’s nearly impossible for me to implement. I’ve abandoned it once already, but came back for automatic page-level code splitting. Now I’m grouchy and I don’t know what do.

Looking for a cleaner example, maybe. Maybe Roxi helps with this, not sure. I know the code is there, but no doc yet, so I’m back where I stared—trying to figure out how it works from the code.

[Wolfr]

@johndunderhill I can understand your frustration, I encountered a similar moment of “ugh, now I have to figure -this- out again” - but there is also no way to move to project that is easier to set up without abstracting the configuration.

There was a move from 1.X to 2.X to abstract away configs. This move is also happening with Roxi. There is a lot of work happening behind the scenes to make things clearer.

In the 1.X situation any upgrade would have to be a manual effort and there would be hundreds of variations of rollup configs out there leading to a lot of support work.

Unfortunately I haven't been Svelting that much over the last few months so I can't point to a clearer example.

[jakobrosenberg]

For what it's worth I'm working on a "simpler" config for Roxi, which once it's done could be ported to the starter template.

However Routify is only a router and it's easy to integrate into any project. You simply have to npm install it, run it and import it. It's completely independent of Rollup.

The starter template however is a production ready template with everything that entails. It's not intended to be integrated into existing projects.

I can create a minimal starter template, but it will look exactly like what you'd get if you installed Routify in the default Svelte template. https://routify.dev/guide/installation/install-to-existing-project

[brgrz]

I concur with @johndunderhill comments and I'd add one more thing: not all of the templates are up to date and the auth template depends on more than dozen packages while the default template only on 5. Also, package versions are off by a lot and I guess the code is behind too. Obv since the auth template hasn't been touched for a few months. However, the readme instructs us to use any template we want so it's somewhat of a bummer when you find out that not all of them are maintained equally.

Having said that, I want to ask does it even make sense to use the other templates at the moment?

[jakobrosenberg]

The new master template has been simplified and the rollup.config.js is is now a single file.

The auth and blog templates are a bit behind the starter template, but should still function as references for implementation of authentication and markdown.

I'm hoping to create a new starter template, with more real-world examples, but time is scarce. If anyone has an idea for how to keep alternative templates uptodate in a painless manner, I'm all ears. PRs are also very welcome.

[brgrz]

I came to this project because I like the concepts and when I saw that there's also a blog template (which I might need very soon) and the auth template, which integrates Auth0 and I need this now, so I thought great, this is what I'm going to take. Unfortunately, and this is not me saying anything bad, after playing around a bit, making some updates to packages (which resulted in a broken build due to some obscure postcss issue), I quickly discovered the 3 template branches are not consolidated/in-sync. From there I resorted to compare&merge and that's when I realized this really isn't how I want to proceed using Routify.

As starters, maybe you could just discard the branches that are not maintained? What's currently in there could be moved to the examples sections? Basically you'd have only one template and then people would add to that by themselves. And the other remaining option, which I think I'm going to take myself now, is installing Routify to an existing Svelte project.

[jakobrosenberg]

Much appreciate the input @brgrz. Your idea for the starter template is along the lines of what I had envisioned for Routify 2.

The only reason I've kept the templates separate is auth0. I'm weary of including dependencies for third party libs which may not be used. I'm still not sure how to handle that.

[braebo]

I like that idea. I think it would be cool to have a separate repo for the examples where community members could contribute templates. I have a few go-to configs that I like to use, so I'd be happy to contribute a template or two. On the other hand, I'd also be happy to take the time to go through the current blog / auth templates and do some housekeeping.

@brgrz you should consider joining the discord, there are a lot of active members that could help you speed up your process when you're in a crunch.

[johndunderhill]

@brgrz @FractalHQ We feel your pain. We have successfully integrated Routify into an existing Svelte project with a moderately complex build proces. This was done entirely by hand, essentially by trial and error.

Everyone's needs are a little bit different. Most projects will not be able to use a starter template as is. There will always be other build components, and runtime dependencies, that may interact with the router. In addition, core functionality tends to escape into templates: some patterns or boilerplate could be incorporated into the library itself, at the expense of some additional abstraction. This may be part of @jakobrosenberg is after with Roxi.

In any case, we feel that there is too much emphasis on templates, per se. In practice, usually we're forced to reverse-engineer the template, so we can apply it to our own use case. This isn't always easy. In this sense, the template is primarily a reference. From our point of view, more complete documentation, covering a broader array of use cases, with lots of simple examples, would have been helpful to us. For me, it's easier to figure out how to combine simple examples, than to untangle a complex template. YMMV.

We'll try to contribute if we can. As always, thanks to the Routify team for a great component.

[jakobrosenberg]

Thanks guys. We take all the help we can get with this stuff. @johndunderhill you're correct about Roxi. It's to separate template functionality from Routify. A lot of features have also been extracted to separate libraries like spank, configent, spassr and tossr. This helps Routify's code and documentation to stay a little leaner while providing a clearer distinction of responsibilities. Especially ones that don't belong in a router.

I have been wanting to do a bunch of examples for a while, but one of my concerns is maintenance. Examples and templates can grow stale quickly and you end up with a trade-off between stale examples and stale development. If @FractalHQ will help with examples and maintenance, that would be a major help. 🙏