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

Support alternate parsers #1444

Open
1 task done
noahw3 opened this issue Aug 30, 2023 · 0 comments
Open
1 task done

Support alternate parsers #1444

noahw3 opened this issue Aug 30, 2023 · 0 comments

Comments

@noahw3
Copy link

noahw3 commented Aug 30, 2023

Is there an existing issue that is already proposing this?

  • I have searched the existing issues

Is your feature request related to a problem? Please describe it

Currently the default parser, dotenv, fails to correctly parse my config file. In particular, it does not support parsing escaped JSON (see motdotla/dotenv#771).

I'm using projen to create the file, which uses the ini library to do so. However, the output files that it creates are not always directly compatible with dotenv as a parser.

The ini parser also supports writing objects as section headers, and then supports parsing them back as well. This is potentially nice functionality to support as well.

Describe the solution you'd like

A new option on ConfigModuleOptions to specify the parser. The default would be the current dotenv parser, but the ini parser would be another option. If necessary, further parser options could be added in the future.

Alternatively, the config option could be the parser function itself. This would enable a BYO parser approach, and not require this library to add any extra dependencies

As far as I can tell, the variable expansion behavior can continue working as is using dotenv-expand without any issue.

Teachability, documentation, adoption, migration strategy

It should be relatively straightforward to add a section to the docs explaining the parser options, and reasons why the ini parser may be preferred over the dotenv parser.

What is the motivation / use case for changing the behavior?

See the problem section above.

V3RON added a commit to V3RON/nest-config that referenced this issue Mar 4, 2024
This commit introduces a new configuration property named parser in ConfigModule, enabling
the injection of custom parser functions. If not specified, the default implementation,
backed by dotenv, is utilized.

closes nestjs#1444
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

No branches or pull requests

1 participant