feat: add resolveConfigPath to return resolved config file path#262
feat: add resolveConfigPath to return resolved config file path#262
resolveConfigPath to return resolved config file path#262Conversation
| Resolve configuration file path: | ||
|
|
||
| ```js | ||
| // Resolve the path to the configuration file without loading it |
There was a problem hiding this comment.
If layers are used resolveConfigPath > resolveSources might also download layer which is not mentioned (also loading dotenv which is a side-effect) ~> #262 (comment)
|
|
||
| const res = await resolveSources(".", options); | ||
|
|
||
| return res.configFile; |
There was a problem hiding this comment.
I feel we could make function more generic like resolePaths or resolveConfig returning an object either full res or a subset, cwd and configFile are particulary useful. If we also resolve rc config, it can be useful for automation scripts to know where to edit/append it. We also have information about layers alrady.
|
|
||
| // Load dotenv | ||
| if (options.dotenv) { | ||
| await setupDotenv({ |
There was a problem hiding this comment.
Do we really need this? It might be helpful for cloning private layers i guess during resoluition but both are hidden side-effects specially if users pass same configuration they expect to pass to resolver and assume it will only try to resolve (not download or filling global env)
I am feeling we could make it opt-in with something like { sideEffect: true } or { loadLayers: true } or avoid side-effects from this function.
|
@danielroe shall we close this? (IIRC wasn't needed in the end) |
|
oh, I think it would stil be useful so we don't have to duplicate logic - but up to you! |
2 participants
nuxt/test-utils#1381 (comment)
this is a first stab at extracting logic for
resolveConfigPath. I've left all behaviour untouched and still running in the same order, just pulled out a couple of routines which seemed relevant for resolving the source file - which means that there's probably scope for simplifying thisI've also switched to explicit exports for
index.tsbut of course that could be reverted