Pass project root as argument to functions that use relative paths

[ashleymichal]

There are a lot of places in our code base where we have to reference a path relative to the root of the project. At the moment, we simply assume that wrangler is always being executed from the project root because that's the only place it will work (we look for the wrangler.toml in the current working directory).

One nice refactor to pave the way to monorepo support, or to simply be able to run wrangler from anywhere in the project, would be to refactor out all these calls to env::current_dir() and pass them in as arguments to the various functions that call them.

per #851 (comment)

[juanmrad]

This would be amazing.

we have been having problems because our project has a couple worker scripts and in order to use wrangler commands we have to go into the folder where the wrangler.toml file is in order to run publish or preview while it would be much nicer to pass just the path of where those files are hosted.

[ashleymichal]

@juanmrad to be clear, this would be a refactor step where internal functions take this as an argument; we haven't quite got to designing how it should look to call wrangler from a directory other than the project root, but it's great to know this use case! are you in a monorepo setup where you cd one directory deeper to get to your wrangler.toml, or a situation where you need to cd a level or two up to get to it?

[juanmrad]

@ashleymichal Yes I understand, but wanted to give my side to help on feedback and also give a scenario where this is useful.

To clarify our use case: We have a monorepo project that contains both front and backend. We currently have 3 different cloudflare worker scripts that are deployed and were created on the UI and we were planning on moving them to the project.

So we added them into a specific folder where each worker scrip has its own folder with its own toml file. Which right now I have to cd two directories deep to each worker script folder in order to deploy them via the CLI.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed because it has not had recent activity. You may re-open the issue if it is still relevant.

[simonhaenisch]

Would like this as well!

[stale]

This issue has been automatically marked as stale because it has not had recent activity in the last 180 days. It will be closed if no further activity occurs in the next week. Please feel free to comment if you'd like it to remain open, and thank you for your contributions.

[Electroid]

Going to close this in favor of #482. Effectively they are about the same thing: allowing developers to specify the workdir (which will involve the refactoring as described in this issue)