Thanks for this - I'd say this should be under output-options instead, after which this looks reasonable

Can we also make sure the JSON Schema is updated?

Thank you for output-options instead of compatibility. I updated JSON Schema (configuration-schema.json file) and I don't know about any other I should update.. I am probably missing something.. Please be more specific if it is this case.

Hi, anyone can help reviewing this PR? Does anyone see more issues or have ideas for improvement? @jamietanna Are you ok with the fixed version?

Looks like there may have been an issue updating the PR as it's now showing commits from main?

@mromaszewicz what do you think about - similar to #2211 - we make this a string parameter which is the Go import path for a net/http compatible router?

Right now, this would be i.e.

output-options:
  std-http-server-router-override: "github.com/julienschmidt/httprouter"

?

I synced the latest content from the main branch and rebased to feat/httprouter branch in my fork. Not sure if it caused issues. Should I update it again?

Looks like there may have been an issue updating the PR as it's now showing commits from main?

@mromaszewicz what do you think about - similar to #2211 - we make this a string parameter which is the Go import path for a net/http compatible router?

Right now, this would be i.e.

output-options:
  std-http-server-router-override: "github.com/julienschmidt/httprouter"

?

@jamietanna What are you going to do with std-http-server-router-override option? I can update it based on the (currently) only specific option value (and the default of course), but it can be more tricky if the other routers are introduced because every router may have different interface and instantiation.

I think it's a fine change in principle, but whenever we see an issue like this, I realize that it can affect every router, every import. There could be a reason to override any import, and the question is, do we want to do it globally, or have a per-template config option.

In due time, I'd like to avoid making default decisions at all, and have all the codegen assumptions be data driven, like here:
https://github.com/oapi-codegen/oapi-codegen-exp/blob/main/experimental/Configuration.md

Currently, we gather up the imports we need from the templates in a pretty simple way, I'm thinking that the answer might be to polish that up and create an override map in the config, eg:

import-overrides:
   net/http: http github.com/julienschmidt/httprouter

hmm, however, that package may not be fully http compatible, so the per-template override makes sense as well.

hmm, however, that package may not be fully http compatible, so the per-template override makes sense as well.

I think import-overrides are not needed for this feature because github.com/julienschmidt/httprouter package does not override net/http. It is rather additional package, so can be handled as follows:

additional-imports:
  - package: github.com/julienschmidt/httprouter
    alias: httprouter

The only question is how to handle "per-template" solution. If to handle it by a flag
use-httprouter-in-std-http-server: true which I understood you don't like OR implement a tricky condition like:

	if opts.Generate.StdHTTPServer {
		for _, ai := range opts.AdditionalImports {
			if ai.Package == "github.com/julienschmidt/httprouter" {
				stdHTTPServerOut, err = GenerateStdHTTPServerWithHttpRouter(t, ops)
				break
			}
		}
		if stdHTTPServerOut == "" {
			stdHTTPServerOut, err = GenerateStdHTTPServer(t, ops)
		}
		if err != nil {
			return "", fmt.Errorf("error generating Go handlers for Paths: %w", err)
		}
	}

What do you recommend?
I am done with the change with this condition and separate templates but I preferred to ask first..

Would this solve your problem today?

In configuration options, we have this:

output-options:
  user-templates: stdhttp/std-http-handler.tmpl: http-handler-with-julientschmidt.tmpl

You could download the template used and include alongside your config file and simply add the header and import which you want there.

I have a few thoughts here:

1. I don't think router-specific settings on the output-options are a good long term thing. If we had router specific settings, I think I'd start adding things like StdHttpConfiguration structs, and put that on Configuration, then we pass those through to the relevant templates and they can access those settings directly.

2. This is a very specific third party package. If we can solve your problem by overriding that one template locally, I don't think we need to make this change for a rare use case.

Would this solve your problem today?

In configuration options, we have this:

output-options:
  user-templates: stdhttp/std-http-handler.tmpl: http-handler-with-julientschmidt.tmpl

You could download the template used and include alongside your config file and simply add the header and import which you want there.

I have a few thoughts here:

1. I don't think router-specific settings on the output-options are a good long term thing. If we had router specific settings, I think I'd start adding things like StdHttpConfiguration structs, and put that on Configuration, then we pass those through to the relevant templates and they can access those settings directly.
2. This is a very specific third party package. If we can solve your problem by overriding that one template locally, I don't think we need to make this change for a rare use case.

I removed output-options completely. and refactored the branch to support the feature with the following configuration:

additional-imports:
  - package: github.com/julienschmidt/httprouter
    alias: httprouter

The condition to select the right template I mentioned is there but the code is more polished, I think.
Tests were added, examples updated.

I also fixed the issues in utils.go and utils_test.go because quite a few tests failed. Let me know if the fixes are OK.

I just found that in go.mod in examples should be correct version of:
require github.com/oapi-codegen/oapi-codegen/v2
but the same issue is in other examples what I see..

Would this solve your problem today?
In configuration options, we have this:

output-options:
  user-templates: stdhttp/std-http-handler.tmpl: http-handler-with-julientschmidt.tmpl

You could download the template used and include alongside your config file and simply add the header and import which you want there.
I have a few thoughts here:

1. I don't think router-specific settings on the output-options are a good long term thing. If we had router specific settings, I think I'd start adding things like StdHttpConfiguration structs, and put that on Configuration, then we pass those through to the relevant templates and they can access those settings directly.
2. This is a very specific third party package. If we can solve your problem by overriding that one template locally, I don't think we need to make this change for a rare use case.

I removed output-options completely. and refactored the branch to support the feature with the following configuration:

additional-imports:
  - package: github.com/julienschmidt/httprouter
    alias: httprouter

The condition to select the right template I mentioned is there but the code is more polished, I think. Tests were added, examples updated.

I also fixed the issues in utils.go and utils_test.go because quite a few tests failed. Let me know if the fixes are OK.

I just found that in go.mod in examples should be correct version of: require github.com/oapi-codegen/oapi-codegen/v2 but the same issue is in other examples what I see..

Actually.. You are right! It works without any changes in the current release !

All I need to do is to configure this:

additional-imports:
  - package: github.com/julienschmidt/httprouter
output-options:
  user-templates:
    stdhttp/std-http-handler.tmpl: templates/http-handler-with-julientschmidt.tmpl

The only hickup is that additional-imports don't work with aliases as in the main branch but it is not important.
I didn't know you support user-templates feature.

Anyway, have a look at my fixes for utils.go and utils_test.go. You have issues there:
34b9d4d
ef6af0c

Thank you !