New tapiro imports

[lvolp]

The idea is to generate imports from controller imports instead of model packages.
If is not possible to find a specific import for a type in a root, all the “._” imports present in the route paths will be included .
This will lead to some unused imports (that can be removed with Scalafix), but adds support to types not present in the model (such UUID,LocalDateTime, etc)

[calippo]

@lvolp testoni

[lvolp]

@lvolp testoni

Ecco cosa mi ero dimenticato 🤣

[tpetrucciani]

I've tried it on our project, and it works for me, with a caveat: at first I got compile errors using the newly generated routes. This was because it was not only adding the controller imports, but also imports from other files (because tapiroRoutesPaths was set to the whole folder of the api module, that includes Boot.scala too, for example). So I got an extra import cats.syntax.reducible._ in addition to cats.implicits._ and they were conflicting.

Once I fixed tapiroRoutesPaths to a folder with only the controllers, it worked.

---

I have a doubt on this approach when relative imports are used:

• In the generated endpoints, I have some relative imports such as import model.X where model is actually myProject.apiGateway.model. These have been copied from the controller.
• These imports work because the endpoints are generated in the same package as the controllers.
• However, if the endpoints were generated in a different package, I suppose these endpoints wouldn't work.

I'm not sure whether this is a serious problem though, so this is probably still OK for now and we'll deal with it if it arises. In practice, I suppose we normally use the same package (or sub-packages such that relative imports still work).

[lvolp]

I have a doubt on this approach when relative imports are used:

• In the generated endpoints, I have some relative imports such as import model.X where model is actually myProject.apiGateway.model. These have been copied from the controller.
• These imports work because the endpoints are generated in the same package as the controllers.
• However, if the endpoints were generated in a different package, I suppose these endpoints wouldn't work.

I'm not sure whether this is a serious problem though, so this is probably still OK for now and we'll deal with it if it arises. In practice, I suppose we normally use the same package (or sub-packages such that relative imports still work).

You're right, I didn’t considered relative imports.
I’m also working on a pr, to run scalafix on generated files.
Scalafix should be able to expand relative imports using a semantic rule.
If relative imports are used in buildo projects, probably the best thing to do is pause this pr and wait for scalafix.

[tpetrucciani]

A few comments on legibility. Maybe some of the complexity can be removed by just generating more imports, even if unneeded, and then eliminating them via scalafix?

Also, some files are not scalafmt-formatted. However, I noticed this is not checked in the CI (and also unrelated files are not formatted properly): I've opened a separate issue #377, so we can fix all formatting in that issue.

[tpetrucciani]

This function is a bit hard to read. I'll suggest a few small changes below, but also: how much of the complexity is done to avoid redundant imports? Since we're getting redundant imports anyway, maybe we can simplify a bit even if we get more of them? (and then either remove them with scalafix or suppress them during compilation)

[tpetrucciani]

Suggested change

	val types = routes.flatMap(tr => tr.route.params.map(r=> r.tpe) ++ (if (tr.route.error.isDefined) List(tr.route.error.get,tr.route.returns) else List(tr.route.returns)))
	val types = routes.flatMap(tr => tr.route.params.map(_.tpe) ++ tr.route.error.toList ++ List(tr.route.returns)))

should be equivalent I think?

[tpetrucciani]

Suggested change

	val typeNameList = types.flatMap(typeNameExtractor(_)).toSet
	val typeNameList = types.flatMap(typeNameExtractor).toSet

[tpetrucciani]

Maybe we could extract a function isWildcardImport instead of repeating this check here and on line 18?

[tpetrucciani]

This is a bit strange since we're first building the strings and then constructing the imports by parsing the strings. I think it would be nicer to build the imports directly using quasiquotes (and maybe extract the strings from them). But I'm not sure if this is too cumbersome, otherwise it's fine to leave as is.

[tpetrucciani]

Maybe use forall or exists instead of filter/isEmpty?

Also, I'm not sure I've understood what the condition in the if means, maybe we can rewrite to

val someMeaningfulNameForTheCondition = controllerPackageStrings.filter(_.endsWith(outputPackage+"._")
val result= if (someMeaningfulNameForTheCondition) controllerPackage ++ importers else importers

using some meaningful name to make this more understandable.

[tpetrucciani]

Let's move the type annotation to after the arguments

[tpetrucciani]

If relative imports are used in buildo projects, probably the best thing to do is pause this pr and wait for scalafix.

They're not used much, and anyway our endpoints are generated in the same package as the controller, so it's not an issue for now (though it would be best to support them in the future).

But it could make sense to add scalafix first if it also allows us to simplify this code by not caring about generating too many imports.