Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

reloading module info generating core failed: #1849

Closed
kokutas opened this issue Jan 25, 2022 · 21 comments · Fixed by #1850
Closed

reloading module info generating core failed: #1849

kokutas opened this issue Jan 25, 2022 · 21 comments · Fixed by #1850
Labels
bug Something isn't working

Comments

@kokutas
Copy link

kokutas commented Jan 25, 2022

What happened?

gqlgen --config ./gqlgen.yml

reloading module info
generating core failed: unable to load github.com/kokutas/graphic/graph/model - make sure you're using an import path to a package that exists

gqlgen.yml

# Where are all the schema files located? globs are supported eg  src/**/*.graphqls
schema:
  - graph/*.graphqls

# Where should the generated server code go?
exec:
  filename: graph/generated/generated.go
  package: generated

# Uncomment to enable federation
# federation:
#   filename: graph/generated/federation.go
#   package: generated

# Where should any generated models go?
model:
  filename: graph/model/models_gen.go
  package: model

# Where should the resolver implementations go?
resolver:
  layout: follow-schema
  dir: graph
  package: graph

# Optional: turn on use `gqlgen:"fieldName"` tags in your models
# struct_tag: json

# Optional: turn on to use []Thing instead of []*Thing
# omit_slice_element_pointers: false

# Optional: set to speed up generation time by not performing a final validation pass.
# skip_validation: true

# gqlgen will search for any type names in the schema in these go packages
# if they match it will use them, otherwise it will generate them.
autobind:
  - "github.com/kokutas/graphic/graph/model"

# This section declares type mapping between the GraphQL and go type systems
#
# The first line in each type will be used as defaults for resolver arguments and
# modelgen, the others will be allowed when binding to fields. Configure them to
# your liking
models:
  ID:
    model:
      - github.com/99designs/gqlgen/graphql.ID
      - github.com/99designs/gqlgen/graphql.Int
      - github.com/99designs/gqlgen/graphql.Int64
      - github.com/99designs/gqlgen/graphql.Int32
  Int:
    model:
      - github.com/99designs/gqlgen/graphql.Int
      - github.com/99designs/gqlgen/graphql.Int64
      - github.com/99designs/gqlgen/graphql.Int32

schema.graphs

# GraphQL schema example
#
# https://gqlgen.com/getting-started/

type Todo {
  id: ID!
  text: String!
  done: Boolean!
  user: User!
}

type User {
  id: ID!
  name: String!
}

type Query {
  todos: [Todo!]!
}

input NewTodo {
  text: String!
  userId: String!
}

type Mutation {
  createTodo(input: NewTodo!): Todo!
}

What did you expect?

Minimal graphql.schema and models to reproduce

versions

  • gqlgen version?
  • v0.14.0-dev
  • go version?
  • go version go1.16.10 darwin/amd64
  • dep or go modules?
  • github.com/99designs/gqlgen v0.16.0
@ubiuser
Copy link
Contributor

ubiuser commented Jan 25, 2022

Seems to be broken with the new release, v0.16.0. For reproduction, just follow the steps at https://gqlgen.com/#quick-start, then try to call go run github.com/99designs/gqlgen generate. It works fine when switching back to v0.15.1.

@frederikhors
Copy link
Collaborator

@StevenACoffman is this a real issue?

@Harika-Soma
Copy link

Facing the same issue as above after following the quick start steps

@ipfans
Copy link
Contributor

ipfans commented Jan 25, 2022

@frederikhors I think we need to update quick start instructions. The empty model directory causes this issue.

@frederikhors
Copy link
Collaborator

@ipfans can you PR please?

@ubiuser
Copy link
Contributor

ubiuser commented Jan 25, 2022

@ipfans The model directory gets cleared during generation, isn't it?

@jakubknejzlik
Copy link

jakubknejzlik commented Jan 25, 2022

@ubiuser yes, it is. I just hit this issue as well with v0.16.0 ... if I switch to v0.15.1 everthing works ok:

...
go mod tidy
go get -d github.com/99designs/gqlgen@v0.15.1
go run github.com/99designs/gqlgen init
go run github.com/99designs/gqlgen generate

@ipfans
Copy link
Contributor

ipfans commented Jan 25, 2022

@frederikhors @StevenACoffman Can we use master branch to gqlgen.com, or we need to tag a new version to update quickstart.

@StevenACoffman
Copy link
Collaborator

Just make a PR for the https://github.com/99designs/gqlgen/blob/master/README.md and I will take care of the rest.

@ubiuser
Copy link
Contributor

ubiuser commented Jan 25, 2022

The code generation is still broken and I believe the change to codegen/config/config.go in 9866507 is to blame.

@StevenACoffman
Copy link
Collaborator

@ubiuser Can you give me an example that reproduces a problem?

@ubiuser
Copy link
Contributor

ubiuser commented Jan 25, 2022

@StevenACoffman Reproduction in a shell with output:

Gabor@DESKTOP-MQ8MBP3 MINGW64 /c/temp
$ mkdir example

Gabor@DESKTOP-MQ8MBP3 MINGW64 /c/temp
$ cd example

Gabor@DESKTOP-MQ8MBP3 MINGW64 /c/temp/example
$ go mod init example
go: creating new go.mod: module example

Gabor@DESKTOP-MQ8MBP3 MINGW64 /c/temp/example
$ printf '// +build tools\npackage tools\nimport _ "github.com/99designs/gqlgen"' | gofmt > tools.go

Gabor@DESKTOP-MQ8MBP3 MINGW64 /c/temp/example
$ go mod tidy
go: finding module for package github.com/99designs/gqlgen
go: found github.com/99designs/gqlgen in github.com/99designs/gqlgen v0.16.0

Gabor@DESKTOP-MQ8MBP3 MINGW64 /c/temp/example
$ go run github.com/99designs/gqlgen init
Creating gqlgen.yml
Creating graph/schema.graphqls
Creating server.go
Generating...

Exec "go run ./server.go" to start GraphQL server

Gabor@DESKTOP-MQ8MBP3 MINGW64 /c/temp/example
$ ls -R ./graph
./graph:
generated/  model/  resolver.go  schema.graphqls  schema.resolvers.go

./graph/generated:
generated.go

./graph/model:
models_gen.go

Gabor@DESKTOP-MQ8MBP3 MINGW64 /c/temp/example
$ go run github.com/99designs/gqlgen generate
reloading module info
generating core failed: unable to load example/graph/model - make sure you're using an import path to a package that exists
exit status 1

Gabor@DESKTOP-MQ8MBP3 MINGW64 /c/temp/example
$ ls -R ./graph
./graph:
generated/  model/  resolver.go  schema.graphqls  schema.resolvers.go

./graph/generated:

./graph/model:

As you can see the generate command clears the generated and model folders and does not re-generate the code, as it previously did with v0.15.1.
The latest addition to the docs that creates an empty doc.go has been deliberately skipped in my steps, because I don't understand why we should have an empty non-generated file in the generated models folder. It feels like a workaround to me somehow, generation should work without magic files.

@StevenACoffman
Copy link
Collaborator

Thanks, that is very helpful for me to understand what you meant, and I agree the current situation is awkward, and adding the empty file definitely is a workaround.

Without an empty non-generated file, you will encounter a problem with the autobind. It will try to autoload the empty dir and fail.
We really want to display any such errors for autobind after generation and reloading, but not before, and certainly not for a completely empty directory.

@ubiuser
Copy link
Contributor

ubiuser commented Jan 26, 2022

I understand now, thank you for the explanation.

@StevenACoffman
Copy link
Collaborator

I would be very excited to get a PR that would allow us to NOT throw an error in this specific case (just haven't generated yet) but DO throw an error when we after we generate the thing we are trying to autobind is still not there. That would help a lot of people getting started to avoid a confusing situation.

@mtibben
Copy link
Member

mtibben commented Mar 1, 2022

I don't believe this should be closed yet - we're saying it's a regression introduced in #1773, right?. gqlgen should handle this gracefully, not require you to add model files manually before running generate

@mtibben mtibben reopened this Mar 1, 2022
@mtibben mtibben added the bug Something isn't working label Mar 1, 2022
Code-Hex added a commit to Code-Hex/gqlgen that referenced this issue Mar 1, 2022
@Code-Hex Code-Hex mentioned this issue Mar 1, 2022
2 tasks
@Code-Hex
Copy link
Contributor

Code-Hex commented Mar 1, 2022

@mtibben please check #2010

@Code-Hex
Copy link
Contributor

Code-Hex commented Mar 1, 2022

write down my go.mod when I checked it

module github.com/Code-Hex/example

go 1.17

replace github.com/99designs/gqlgen => ../gqlgen

require (
	github.com/99designs/gqlgen v0.16.0
	github.com/vektah/gqlparser/v2 v2.4.0
)

require (
	github.com/agnivade/levenshtein v1.1.0 // indirect
	github.com/cpuguy83/go-md2man/v2 v2.0.1 // indirect
	github.com/gorilla/websocket v1.4.2 // indirect
	github.com/hashicorp/golang-lru v0.5.0 // indirect
	github.com/matryer/moq v0.2.3 // indirect
	github.com/mitchellh/mapstructure v1.2.3 // indirect
	github.com/russross/blackfriday/v2 v2.1.0 // indirect
	github.com/urfave/cli/v2 v2.3.0 // indirect
	golang.org/x/mod v0.5.1 // indirect
	golang.org/x/sys v0.0.0-20211019181941-9d821ace8654 // indirect
	golang.org/x/tools v0.1.9 // indirect
	golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1 // indirect
	gopkg.in/yaml.v2 v2.2.8 // indirect
)

@mtibben
Copy link
Member

mtibben commented Mar 1, 2022

I think I misunderstood. In any case, the original issue I can't reproduce any longer, so I think #1850 can be reverted

@mtibben mtibben closed this as completed Mar 1, 2022
@Code-Hex
Copy link
Contributor

Code-Hex commented Mar 1, 2022

@mtibben I understand what you want saying.
actually we can not reproduce this issue at master branch following this.

I'm also thinking we can just revert c99fde1

@StevenACoffman
Copy link
Collaborator

StevenACoffman commented Mar 1, 2022

When following the directions, users got an error because gqlgen cannot autobind to an empty models directory.
The workaround was to either comment out autobind in the config or put an empty model file in there. We did both, which is like wearing both a belt and braces (suspenders / サスペンダ ?). Reverting the prtinf is fine as long as the autobind is still commented out, or we avoid the error completely in this case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants