-
Notifications
You must be signed in to change notification settings - Fork 55
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
Resolving manually provided config file #106
Comments
I personally do not feel a plugin should accommodate non-standard behavior. What is your reasoning for trying to change the name of the package file? |
The problem I encountered is not caused by the file name - it is all about file path. So, even './../../package.json' will result in an error (at least on Windows). The solution I proposed takes care of both file path and file name while being platform-agnostic. Regarding the file name per se - as I understand it: the whole idea of config option is to target the configuration file - whatever it may be named (as long as it respects the configuration format). Actually I never thought about why one might use different filename (or another file altogether) to handle Gulp modules, but that is completely irrelevant at this point. I ended up using different filename during debugging since it helped me avoid the behavior shown above in the second picture. |
If you do Thanks for writing this up though - I will try to take a more detailed look at it soon. If you could get the above examples into repos I could grab and work with that'd be really useful :) |
@jackfranklin, providing the config object by doing Keep up the good work! |
@mwessner sorry I never replied to this comment - do you fancy making a PR with those documentation changes? That would be much appreciated if you have the time :) |
Hi! This is a follow-up on previous PR/issue on resolving manually provided config file. Let's try to get to the bottom of this...
The problem I initially faced happens in the following scenario:
OS: Windows 10 Pro.
Shell: PowerShell 5.0.10586.122
Here is the relevant file structure on the filesystem:
Here is the content of simplified 'test_package.json' file:
Here is the content of simplified 'testing/gulpfile.js' file:
When I try to run the Gulp script from within the root directory I get the 'Cannot find module...' error, like so:
Changing the 'configObject' declaration solved the particular issue, but it was not a valid solution! I did not go deep enough into the problem... The case is: if our config file is named 'package.json' (which is the default value) but we do provide config path as './package.json' (which should be legit) - it resolves to 'package.json' of gulp-load-modules package:
and it consequently results in an error shown bellow:
I guess, this behavior is the result of search path starting from CWD. If our config is defined in a file named anything other than 'package.json', the error shown first above arises (in my case the config file was named 'test_package.json').
So, here is another simple test case (as noticed by @goyney) which highlights the real problem:
Here is the relevant file structure on the filesystem:
Content of 'test_package.json' file remains the same.
Here is the simplified content of 'testing/gulpfile.js' file:
When I try to run the Gulp script from within 'testing' directory I get the 'Cannot find module...' error, like so:
And when I change the 'configObject' declaration to call 'configureFn' I get the following error:
After putting some more effort to it I realized it was a problem of config file path, not the invoking function. So, here is proposed solution - adding the following block of code after options initialization:
This solves it for me - 'configObject' declaration stays the same ('require()' is used), but it resolves correctly for both './configfile' and './../configfile'.
Sidenote: It is hard for me to believe this problem did not surface earlier. I was testing this on Windows platform only, so it might be that on other platforms filepaths are resolved correctly even though no explicit 'path.normalize()' and 'path.resolve()' are utilized.
Can you please look into it...
P. S.
I am working on more than a few things at the moment, so I might not be able to respond promptly. :(
The text was updated successfully, but these errors were encountered: