Pub serve outside of web/

gistfile1.md

Spent a bunch of time talking to Nathan, Siggy, and Kevin about how to handle pub serve with stuff outside of web/. Our goals are:

1. Root-relative URLs inside web/, test/, example/, and even things like subdirectories of example/ should be supported. This means that the root directory being served needs to be constrained to those.

   We can't require the user to hit localhost:8080/example/example1/foo.html because it would break a root-relative URL in foo.html.

2. More than one of these directories needs to be servable simultaneously. If you have to shut down the server and restart it (which entails rebuilding everything) every time you switch between running your app and running its tests, that would suck.

3. The Editor needs to have an easy way of knowing what URL to hit when the user picks a file and wants to run it.

We have a bunch of other goals and constraints we talked about, but I think those are the main forcing functions. After a bunch of discussion, what we came up with is:

Pub serve supports serving multiple root directories on different ports. In addition, it uses one port for an (initially minimal) web interface to give you something simple to click to get to those other ports. A user on the command line can do something like:

$ pub serve web test example/sample1 example/sample2
Serving package "foo" on localhost:8080...
- port 8081: web
- port 8082: test
- port 8083: example/sample1
- port 8084: example/sample2

When they go to localhost:8080, it gives them a page with links for "web", "test", "example/sample1", etc. Each of those just goes to localhost:<n> where n is some other port that pub serve opened. Eventually, we can add the ability to turn on serving out of other directories in this little UI.

In the Editor, it can start up pub serve and then connect to pub's web socket API. From there, it can issue commands to bind ports to different directories or unbind them. This lets the Editor keep the server running independently of which directories the user currently cares about.

How important is "More than one of these directories needs to be servable simultaneously." ? I haven't personally needed that use case, but that's anecdotal. I don't think I would mind having to do:

pub serve web
pub serve example

Also, why does shutting it down and restarting imply rebuilding? Couldn't we eventually cache the results of a build? (I know I found it slow to use pub serve because it did rebuild the world every time I started it up, so +1 for caching :)

I'd be a bit worried about assuming too much about port ranges. Just cause I assign 8080 to pub serve, does that really mean 8080-8084 ?

Maybe if we labeled it "--start-port" or something clear that it's n...n+4 (or whatever it is)

I don't know if the intent here is to serve all these services at the time by default. Start up performance may become an issue. I share Seth's views. Giving the user the ability to specify what directories to serve might be the way to go. The default (as would be expected) should be serving "web" if nothing else is specified. Also, giving the user the ability to specify ports as Seth suggested adds even more power.

@zabzal I assume we'll be able to specify what port we want to start pub to serve off of. Was just curious what happens if 8081 is in use (assuming we start on 8080)

FWIW thanks for considering (1)! I agree, that's a big deal. I'd like my URLs to be the same when I'm serving from production.