resolve before require

[laggingreflex]

Fixes deepsweet/start#24

[deepsweet]

nice one! will test it.

[deepsweet]

trying to find a reason to have !fs.existsSync(modulePath) here and can't. looks like resolveCwd(`./${commander.file}`) already solves all the local path cases. part of my testing code:

let modulePath = null;

if (commander.preset) {
  modulePath = resolveCwd(commander.preset);

  if (!modulePath) {
    console.error(`Unable to resolve "${commander.preset}" preset`);
    process.exit(1);
  }
} else {
  modulePath = resolveCwd(`./${commander.file}`);

  if (!modulePath) {
    console.error(`Unable to find "${commander.file}" file`);
    process.exit(1);
  }
}

const tasks = require(modulePath);

what do you think?

[laggingreflex]

Yeah it's redundant. Updated

[laggingreflex]

It seems this has been merged and version update to 4.1.1 but not been published to npm yet. Just letting you know in case you forgot to actually publish, unless you meant to publish later which is cool.

Also babel-cli has simple-cli's version 4.0.0 which in theory should install version 4.1.1 but it seems yarn still installs 4.0.0 - yarnpkg/yarn#2364. It'd be great if you updated simple-cli's version in babel-cli as well. It helps bust cached version.

[deepsweet]

oops, published.

Also babel-cli has simple-cli's version 4.0.0 which in theory should install version 4.1.1 but it seems yarn still installs 4.0.0

that's because yarn.lock (only the last one, ie your in current your project) is already respected. try yarn upgrade or even install it with yarn.lock deleted. so if you install Start and its dependencies in your project for the first time, the latest versions from semver ranges will be installed for sure, but after that it's up to you to bump them every time.

the point of Yarn is that you have to control all the dependencies tree "manually", nothing is updated magically.

[deepsweet]

ok, now I see the bug.