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

Export prepareConfig #98

Merged
merged 8 commits into from
Mar 10, 2019
Merged

Export prepareConfig #98

merged 8 commits into from
Mar 10, 2019

Conversation

sttk
Copy link
Contributor

@sttk sttk commented Mar 2, 2019

Sorry, I forgot to export prepareConfig. This pr modifies Liftoff as follows:

  1. Adds Liftoff.prototype.prepareConfig.
  2. Changes findCwd(opts) to env.cwd for requiring modules specified by env.require.
    This modification brings no change on behavior but becomes more simple.
  3. Moves resolving symbolic link for env.configPath into prepareConfig.
    Because it's needed to resolve symbolic link for env.configPath by .gulp.json, too.

@sttk sttk requested a review from phated March 2, 2019 15:45
phated
phated previously requested changes Mar 2, 2019
Copy link
Member

@phated phated left a 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?

README.md Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
lib/prepare_config.js Outdated Show resolved Hide resolved
if (env.configPath) {
// resolve symlink if needed
if (fs.lstatSync(env.configPath).isSymbolicLink()) {
env.configPath = fs.realpathSync(env.configPath);
Copy link
Member

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.

Copy link
Member

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?

Copy link
Contributor Author

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.

Copy link
Member

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?

Copy link
Contributor Author

@sttk sttk Mar 3, 2019

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.

@sttk
Copy link
Contributor Author

sttk commented Mar 6, 2019

I've updated this pr.

  • Remove resolving symbolic link of configPath.
  • Remove lib/prepare_config.js.
  • Add Liftoff.prototype.configure, preloadModules and registerLoader instead of prepareConfig.

@phated
Copy link
Member

phated commented Mar 6, 2019

@sttk these changes are great!! I think I'm going to adjust the API a little bit (hopefully in a backward-compatible way).

@phated
Copy link
Member

phated commented Mar 6, 2019

@sttk I just pushed a change to your fork that splits the launch method into 2 separate methods, a prepare(opts, fn) and an execute(env, fn). Then launch uses them to retain the previous behavior. However, in gulp-cli, we can use the methods independently like:

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 async/await)

@phated phated dismissed their stale review March 6, 2019 18:32

More changes happening

@sttk
Copy link
Contributor Author

sttk commented Mar 7, 2019

@phated Interesting! I think those changes are good!

I'm also thinking about making these APIs Promise-returning in the future so they can be used with async/await

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?

@phated
Copy link
Member

phated commented Mar 7, 2019

@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?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sttk thoughts on this?

Copy link
Contributor Author

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.

Copy link
Member

@phated phated Mar 9, 2019

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.

@phated
Copy link
Member

phated commented Mar 7, 2019

@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?

Copy link
Contributor Author

@sttk sttk left a 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?
Copy link
Contributor Author

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.

README.md Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
test/fixtures/prepare-execute/nodeflags_only.js Outdated Show resolved Hide resolved
@phated
Copy link
Member

phated commented Mar 9, 2019

@sttk I've addressed all of your comments and made execute take the forcedFlags as the 2nd argument. Let me know if these changes look good and I can merge and make a release.

Copy link
Contributor Author

@sttk sttk left a 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!

README.md Outdated Show resolved Hide resolved
@phated phated merged commit 25a40f3 into gulpjs:master Mar 10, 2019
@phated
Copy link
Member

phated commented Mar 10, 2019

💥 🎉 :shipit: @sttk thank you so much for getting this PR started. I will get it released shortly.

@phated
Copy link
Member

phated commented Mar 10, 2019

3.1.0 published!! I'm excited to get this into gulp-cli and fix up some of our outstanding issues!

@sttk
Copy link
Contributor Author

sttk commented Mar 11, 2019

@phated Thank you very much!

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

Successfully merging this pull request may close these issues.

None yet

2 participants