-
Notifications
You must be signed in to change notification settings - Fork 337
Conversation
@@ -31,7 +31,7 @@ pub struct Manifest { | |||
pub workers_dev: Option<bool>, | |||
#[serde(default = "some_string")] | |||
pub route: Option<String>, | |||
pub routes: Option<HashMap<String, String>>, |
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.
interested in why this was a hashmap to begin with - i know we never used it anywhere but still interested
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.
because technically routes are a map between a pattern and a script, and it is potentially useful within a Wrangler project if you wanted to "negate" a route by setting it to a null
worker. For the purposes of this refactor, I am starting with the simplest implementation - a list of patterns - to reach parity with serverless.
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.
makes sense - will this bite us at all when we try to migrate? will the future require breaking changes to the toml? would like to avoid that as much as possible
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.
predicting the future of routes is about as easy as predicting next year's weather (probably will be hotter than today, but who knows if it'll be raining). That being said, if it is clear before release that we need this data structure to change we can do that.
src/settings/target/target.rs
Outdated
let mut routes = Vec::new(); | ||
|
||
if let Some(single_route) = &self.route { | ||
if self.routes.is_some() { |
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.
this case isn't covered in the else and should probably be brought out to the top -
if &self.route.is_some() && &self.routes.is_some() {
failure::bail!("You can specify EITHER `route` or `routes` in your wrangler.toml")
}
(also it shouldn't have a trailing semi-colon i think)
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.
what do you mean "this case isn't covered in the else"?
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.
in the else if let Some(multi_route)
block, we do not check to see if there is also a route
field. I see now that if they were both there, the first block would catch it, but I still find it a bit strange that we check if both exist after we check if one exists. I think I'd have it as its own separate block like I describe above even though they would be functionally equivalent.
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.
yeah covering it in both places would be redundant. i'll pull up the first case. is that really blocking then?
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.
yay :):)L):):): I:P):)):)
sob. all my tests are borked. cloudflare-rs should be published sometime today i think |
More intermediate refactors as we move toward multiroute support.
route
setting androutes
setting, asserting that only one can be specified in the wrangler.toml, and generalizing them to a VecTODO: