Engine package?

[dylanhitt]

Similar to what we did with options: https://github.com/go-fuego/fuego/blob/main/option/option.go. What are thoughts on creating an engine package that holds all the configuration capabilities for engine?

I mention this as a colleague mentioned to be that is is difficult to distinguish fuego Server options from Engine options.

[phlashdev]

I have another idea that could bring more clarity for options in general. We could introduce named types for the options.

type EngineOption func(...) ...

func WithTowel() EngineOption {
    ...
}

These would make EngineOption appear in the package docs on pkg.do.dev, and all functions that return this type would appear directly beneath it. I'd consider this more idiomatic.

But if there are many options with similar names, then separate packages are probably a good idea. In this case, I would propose that we rename the options package to route or endpoint for better clarity.

[phlashdev]

I will try to find me some time and make a PR for this!

[EwenQuim]

Related PR #530 . Merged, thanks for your suggestion!

[dylanhitt]

After seeing #530 I'm pretty on board with our current options having this done as well. Also I'm pretty sure I agree with options -> route. We have too many options to really call anything just an option

[phlashdev]

Didn't look into it already, but if we don't have any function name clashes, we can probably leave all of these options with their dedicated types in the fuego package? Are there any other reasons for having routes, params, etc. packages?

Type aliases could help here, so the existing code would not have to change immediately.

[dylanhitt]

#539 is loosely related to this.

@phlashdev to answer you question. Technically no, but semantically yes. The decision to create the option package was to provide a bit nicer way of discovery for finding options related to routes. (I do now like the name route better now that you point that out.) Now since you've pointed out the types idea and how it appears in the go doc maybe us doing that was kinda superfluous.