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

Importing configs from other packages results in an empty value #20

Closed
miniscruff opened this issue Apr 11, 2024 · 2 comments · Fixed by #24
Closed

Importing configs from other packages results in an empty value #20

miniscruff opened this issue Apr 11, 2024 · 2 comments · Fixed by #24

Comments

@miniscruff
Copy link
Contributor

Consider a project layout such as

> config
    > env.example
    > CONFIGURATION.md
    > config.go
> models
    > config.go

If the config/config.go imports the models/config.go as part of its config, the resulting envdoc output will simply show as empty.

//go:generate go run github.com/g4s8/envdoc@latest -output CONFIGURATION.md -type Config -field-names
//go:generate go run github.com/g4s8/envdoc@latest -output .env.example -type Config -field-names -format dotenv

// Config manages all our app configurations.
type Config struct {
	Database models.PostgresConfig `envPrefix:"DB_"`
	// not included is my postgres config but imagine it has username, password, host, etc
}

Resulting markdown file:

# Environment Variables

## Config

Config manages all our app configurations.

 - `DATABASE` - 

I believe the issue is also relevant if you were importing from an entirely different project as well.

@miniscruff
Copy link
Contributor Author

@g4s8 definitely not trying to be pushy or rude but I do want to mention this again just in case it was missed. I would also be willing to take a look at doing it myself if it was a matter of time on your side.
Thanks again.

@g4s8
Copy link
Owner

g4s8 commented May 8, 2024

@miniscruff thanks for reminding my. This task could be a bit more complex as expected. First we need to restructure the ast parser to include package name context as a part of any type definition and then use it for type matching. Next, it's needed to support an additional flag pointing to project root. A new file-set should be created using the project root as a starting point. I'm going to do these tasks one by one. I'd really appreciate if you could help with any.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants