-
-
Notifications
You must be signed in to change notification settings - Fork 51
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
Export prepareConfig #98
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After going through this whole PR, I'm wondering if you can separate the Liftoff.prototype.prepareConfig
stuff from the fixes in lib/prepare_config.js
into separate PRs. The symlink stuff should land as a patch version and then we can work through some of the prepareConfig
normalization changes. Thoughts?
lib/prepare_config.js
Outdated
if (env.configPath) { | ||
// resolve symlink if needed | ||
if (fs.lstatSync(env.configPath).isSymbolicLink()) { | ||
env.configPath = fs.realpathSync(env.configPath); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was going to ask if this belonged in this file but it was always named weird. We weren't really "preparing" any config, we were just loading explicit requires and loaders.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this solve a gulp-cli issue?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not confident about this naming. Certainly this part is just loading opts.requires
and loader for configPath
. Additionally I want to give the application a chance to change env
object here before the loading. Should we provide an empty method (like Liftoff.prototype.prepareConfig
) and execute this loading after the method?
Does this solve a gulp-cli issue?
This modification is not for solving any issues. If this symbolic link resolving is needed, this should be applied to configPath
by not only cli option but also config files.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As per the comment above, do we want to remove this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. All tests except a case for symbolic link have passed even without this symbolic link resolving. It's no problem to remove this.
…lve symbolic links for itself.
…eloadModules and registerLoader instead.
I've updated this pr.
|
@sttk these changes are great!! I think I'm going to adjust the API a little bit (hopefully in a backward-compatible way). |
@sttk I just pushed a change to your fork that splits the var cli = new Liftoff()
cli.prepare(opts, function(env) {
var cfgLoadOrder = ['home', 'cwd'];
var cfg = loadConfigFiles(env.configFiles['.gulp'], cfgLoadOrder);
opts = mergeConfigToCliFlags(opts, cfg);
env = mergeConfigToEnvFlags(env, cfg);
env.configProps = cfg;
cli.execute(env, function() {
// post-launch stuff
});
}); What do you think about these changes? If they seem good, we can document them and refactor the tests. (I'm also thinking about making these APIs Promise-returning in the future so they can be used with |
@phated Interesting! I think those changes are good!
That code will become as follows? const cli = new Liftoff()
async function run() {
const env = await cli.promisifiedPrepare(opts)
// process configFiles
await cli.promisifiedExecute(env)
// post-launch stuff
}
run() And will you drop support of older nodejs versions than v7.6 in the near future? |
@sttk perfect, I'll finish up the rest of this today and then you can do a full review! As for the promise stuff, that will probably be in the next major release after we get some of these little things fixed, but your proposed syntax would be correct (the methods likely won't be renamed though). I'm still trying to determine when the older node versions will be dropped because gulp has a subset of users still on old versions. |
index.js
Outdated
}; | ||
|
||
// TODO: Does the "prepare" phase allow us to get rid of this normalization? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sttk thoughts on this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
flaggedRespawn(flags, argv, [forcedFlags,] execute)
regards forcedFlags
as execute
when forcedFlags
is a function. At least, the normalization to avoid forcedFlags
not being a function is needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sttk I'm thinking that forcedFlags
should only be an option on launch. The execute
command can take env
and forcedFlags
arguments before the callback. I'll make this change.
@sttk I've updated the docs and the tests for these changes. Please review and let me know if anything should be changed. Also, can you make sure I didn't break anything in the gulp-cli test suite with these changes? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@phated I've reviewed and requested some changes.
This prepare/execute
separation is elegant!
index.js
Outdated
}; | ||
|
||
// TODO: Does the "prepare" phase allow us to get rid of this normalization? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
flaggedRespawn(flags, argv, [forcedFlags,] execute)
regards forcedFlags
as execute
when forcedFlags
is a function. At least, the normalization to avoid forcedFlags
not being a function is needed.
@sttk I've addressed all of your comments and made |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@phated There is one thing I want you to corrent my mistake.
Except this, I think all is good. Excellent!
💥 🎉 @sttk thank you so much for getting this PR started. I will get it released shortly. |
3.1.0 published!! I'm excited to get this into gulp-cli and fix up some of our outstanding issues! |
@phated Thank you very much! |
Sorry, I forgot to export
prepareConfig
. This pr modifiesLiftoff
as follows:Liftoff.prototype.prepareConfig
.findCwd(opts)
toenv.cwd
for requiring modules specified byenv.require
.This modification brings no change on behavior but becomes more simple.
env.configPath
intoprepareConfig
.Because it's needed to resolve symbolic link for
env.configPath
by.gulp.json
, too.