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

Disable some "defaults", like local.{ext} loading #756

Open
marlon-sousa opened this issue Jan 17, 2024 · 3 comments
Open

Disable some "defaults", like local.{ext} loading #756

marlon-sousa opened this issue Jan 17, 2024 · 3 comments

Comments

@marlon-sousa
Copy link

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

I am using this libary as base for my own library.

My library restricts some what the available options of this one, as to enforce some standards.

My problem is the following: I would like to disable loading of all kinds of files which are loaded if present, as for example the local.{ext} ones.

Hosts and deployments files are also not desirable in my use case.

Describe the solution you'd like

I would create a second parameter for util.loadFileConfigs, an "options" parameter. This might be an object , default {}, which could allow an ignoreFiles = [] key.

This key would accept a list of pre determined values, to specify files to be ignored while loading:

  • "DEFAULT": if present, ignores default.EXT and default-{instance}.EXT
  • "DEPLOIMENT": if present, ignores deployment.EXT and deployment-{instance}.EXT
  • "SHORT_HOST": if present, ignores {short_hostname}.EXT, {short_hostname}-{instance}.EXT, {short_hostname}-{deployment}.EXT
    and {short_hostname}-{deployment}-{instance}.EXT
  • "FULL_HOST": if present, ignores {full_hostname}.EXT {full_hostname}-{instance}.EXT, {full_hostname}-{deployment}.EXT, {full_hostname}-{deployment}-{instance}.EXT
  • "HOST": if present, ignores what is ignored by "SHORT_HOST" and "FULL_HOST"
  • "LOCAL": if present, ignores local.EXT, local-{instance}.EXT, local-{deployment}.EXT and local-{deployment}-{instance}.EXT

Describe alternatives you've considered

As it is, there is nothing I can do about it, at least not that I can think of. I am opemning this issue because an user of my library reported that they have a local.{ext} file which was accidentally loaded when they didn't want it.

Please tell us about your environment:

  • node-config version: 3.3.9
  • node-version: from 12 to 18

Other information

I am whiling to try a pr but only if such feature would be accepted. My understanding is that because we would create an empty by default options object this wouldn't break compatibility, yet it would add functionality for those who need it.

@norbertroamsys
Copy link

We have more or less the same or an equivalent issue:
On one of our servers the hostname is the same as one of the NODE_ENV names.
As a consequence the "unwanted" hostname config file is loaded instead of the NODE_ENV config file (as documented in File load order).

An option (as descripted by @marlon-sousa) to e.g. exclude the hostname files from being loaded would help!

@markstos
Copy link
Collaborator

This came up before in #337

There I'm not a far of declaring what you aren't doing-- in this case, declaring what you are ignoring. It would be clear if there was a way to declare what you wanted to load, rather than what you don't want to load.

Why not just override util.loadFileConfigs in you private class so that it loads exactly what you want?

@norbertroamsys
Copy link

norbertroamsys commented May 27, 2024

Yes - a way or strategy to define just what we wanted to be loaded would be the best. Options for ignoring are mostly a workaround for sure!

What do you mean with ...

Why not just override util.loadFileConfigs in you private class so that it loads exactly what you want?

It also sounds like a dirty workaround which may make problems in further node-config releases.
If no: Can you provide a code snippet or an example for a proper usage?

Thanks for helping!

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

3 participants