fix: Config should be resolved relative to the entrypoint

[threepointone]

During dev and publish, we should resolve wrangler.toml starting from the entrypoint, and then working up from there. Currently, we start from the directory from which we call wrangler, this changes that behaviour to start from the entrypoint instead.

(To implement this, I made one big change: Inside commands, we now have to explicitly read configuration from a path, instead of expecting it to 'arrive' coerced into a configuration object.)

Fixes #440.

[changeset-bot]

🦋 Changeset detected

Latest commit: 7617b61

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
wrangler	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[github-actions]

wrangler prerelease is available for testing:

npm install --save-dev https://prerelease-registry.developers.workers.dev/runs/1838037310/wrangler

[petebacondarwin]

OK, so this is what I am getting at. How about we write the beginning of the readConfig() to be like:

async function readConfig(
  configPath: string | undefined = "wrangler.toml",
  cwd = process.cwd()
): Promise<Config> {
  // TODO - terminate this early instead of going all the way to the root
  configPath = await findUp(configPath, { cwd });

  const config: Config = configPath
    ? TOML.parse(await readFile(configPath, "utf-8"))
    : {};

  ...
}

Then for most of the commands we can just run:

const configPath = args.config && path.resolve(args.config);
const config = await readConfig(configPath);

And for dev and publish we would use:

const configPath = args.config && path.resolve(args.config);
const config = await readConfig(configPath, args.script && path.dirname(args.script));

[threepointone]

Could you explain why you think this is better? In your version, the signature is a bit confusing, because it implies the second arg is necessary even if configPath is truthy. I might be missing some context.

[petebacondarwin]

Could you explain why you think this is better? In your version, the signature is a bit confusing, because it implies the second arg is necessary even if configPath is truthy. I might be missing some context.

OK, so thinking about this some more. I am happy to drop my idea above. It does make the signature a bit weird.

Happy to go with what you have here. We could probably knock around a number of different approaches but they all have their limitations and this looks pretty robust.