Do not overwrite cwd if knexfile and cwd is passed #6060
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When having both
--cwd
argument and--knexfile
argument, the knexfile basepath overwrites the process cwd which is strange IMO.If we pass
--cwd
it should have higher precedence than the basepath of the--knexfile
for process cwd selection.My use case for knex is strange. I'm trying to integrate it in firebase project and I want the configuration values for password and username to be loaded by firebase runtime configuration.
The file structure looks like this
I wanted the
knexfile.ts
andmigrations
to be undersrc
directory but the.runtimeconfig.json
should be in the parent directory and it contains the values for those variables.When I execute from
.
:the working directory is initially
.
but after that it is overwritten by./src/
.You cannot tell to firebase where to find its .runtimeconfig.json. It always search for it in the current working directory I think.
I found two pull requests that are related to that topic and based on this PR #3613 and the table which was created by @briandamaged (https://docs.google.com/spreadsheets/d/19TMouhxdIosYGzubO-2lbxm8Ykx4jR-Iu74HXohFYMg/edit#gid=0) I realised that this might be a bug which I think was introduced by PR #4122.