go

go copied to clipboard

As requested on https://blog.golang.org/pkg.go.dev-2020: I have found godoc.org to be the best way to search for quality Go modules, significantly because it defaults to sorting by the number of imports (possibly informed by the number of stars).

Compare: https://pkg.go.dev/search?q=smtp

To: https://godoc.org/?q=smtp

Observe, for instance, that on godoc.org, Brad Fitz's smtpd server comes up early, whereas on pkg.go.dev the front page has several packages of much less importance, and smtpd shows up on page 17 after a lot of inner modules and minor forks and larger projects that just happen to have an "smtp" package. Prioritizing hits at the "top level" of the package is probably a good idea, too; github.com/blah/smtpd is much more likely to be what I'm looking for than github.com/blah/project/go/inner1/inner2/smtp.

I also routinely suggest this to newcomers as a way of locating modules for Go.

Thanks for the investigation! Looking into it. It could have something to do with a change to openapi-typescript-helpers. I think I’m going to add tests for different moduleResolutions somehow. Could or could not be the problem based on #1634, but couldn’t hurt to eliminate that as a possibility. This seems like a bug, as TSConfig settings shouldn’t affect type safety.

Let me know if I can help - I had a sniff that the helpers might be involved too but I couldn't quite see how. There are a number of typing related changes in there, so it's a bit beyond my limited current understanding of the type infra here.

Is this theoretically fixed? I think it is but I have only seen that the playground errors now (as it should). But before I go through the variety of deps to update would love to know it was intentional :)

Running into exactly the same problem, currently stuck on 0.9.3, all versions afterwards lose all type information.

Whereas it used to work :)

Tried both openapi-typescript-helpers 0.0.7 and 0.0.8, no difference in the generated output together with openapi-typescript 6.7.6

My tsconfig.json has both module and moduleResolution set to NodeNext.

Investigated this a little further and in planning for the upcoming 0.10.0 release (which requires [email protected] which will also get a stable release at the same time) this is hopefully fixed. Or if not fixed, easier to debug.

I believe some of this came from [email protected] generating a lot of partial schemas, which made inference harder. 7.x generating full schemas with never types means openapi-fetch can get simpler inference, and easier cross-comparison since all shapes are fully outlined. Or that’s the hope, at least.

Some of the type inference that I believe led to the regression has been changed in 0.10.0. Are people still seeing the failures with the latest version?

Not resolved here.

Bumped both fetch and generator to latest, regenerated, but no types. Using nodenext.

It seems to be resolved with [email protected] and [email protected]. Thanks :)

Thanks @Baldinof. Issue is still open because we didn’t find the original root cause as to what went wrong. But when it comes to advanced TypeScript inference, combining lots of objects that can differ from one user to the next, it’s easy to create “impossible unions” of types. openapi-typescript@7 was the first version released since openapi-fetch came out, and it generates a lot of key?: never types which at first glance seem like wasted boilerplate, but actually help make inference more efficient and more accurate (TS likes when all the shapes are the same).

I suspect the original issue had to do with the perfect storm of limitations of openapi-typescript@6 coupled with openapi-fetch working around those limitations as best it could, and some user-generated schemas not being in our test suite. Whether or not we could have solved it on the previous versions is hard to say. But either way, will leave this issue open for longer to see if others report problems with the current versions.

I think I'm still having this problem :-( (with latest versions: "openapi-fetch": "0.12.0", "typescript": "5.6.2")

For a Node project, the only way I get types is with "module": "CommonJS", in tsconfig, setting "module": "NodeNext", breaks it.

Is any reproduction available? I have a project at work that

• uses ESNext modules (esm = transpiles into import/export syntax)
• tsconfig moduleResolution set to "Bundler"
• package.json has type: "module" to indicate that esm should be used (I guess)

The module system in javascript is a bit complicated to say the least (there's some light reading available at https://www.typescriptlang.org/docs/handbook/modules/theory.html#the-module-output-format).

edit: forgot to say that in the case of my project, I don't get this issue

I think I figured out my problem, if I switch the TS "module" type I also need to add file extensions to the imports of the files (for modern/ESM format) it seems. So I guess that makes sense :-)