I'm fine with it being one big commit. Don't see any obvious red flags, I'll give it a proper review and a test drive come Monday. Will let you know how that goes. Thanks!

Simple case seems to be working well. Going through the code.

What do you think of making the deploy process for Universal like this by default though:

1. prerender
2. dist/browser gets deployed to Firebase hosting
3. dist/server gets deployed to Cloud Functions with the ** pass-through on hosting

That way all the static assets / prerenders are on the CDN w/o need for cold-start. We could also give the developer some options here:

? We detected an Angular Universal project. Would you like to prerender on deploy? Yes
? Deploy browser assets to Firebase Hosting? Yes
? Deploy server assets to Cloud Functions? Yes
UPDATE package.json (2302 bytes)
✔ Packages installed successfully.
✔ Preparing the list of your Firebase projects
? Please select a project: (Use arrow keys or type to search)
❯ Project A
  Project B
  Project C

Currently, the generated firebase.json would look like this:

{
    "target": "project",
    "public": "dist/browser",
    "ignore": ["firebase.json", "**/.*", "**/node_modules/**"],
    "rewrites": [
      {
        "source": "**",
        "function": "ssr"
      }
    ]
  }
}

My understanding is that we deploy static assets to a CDN and we have the ** rewrite to a firebase function. I intentionally didn't do prerendering since I'm not sure if everyone would want to opt-into that.

Ok, fair enough on the prerender; we can always see if that's requested later down the road.

** will cache it behind the CDN, due to the maxAge in server.ts, but only after the first time it's requested and the file hasn't been deployed to hosting. It's a reverse proxy (on cache miss) model. Deploying the static assets to hosting first would ensure that they're the freshest, even if they didn't change the filename (different eviction model), and won't be subject to coldstart...

That said, I missed that you were already deploying the browser bundle to hosting. So ignore that feedback 😃

Also general feedback, the deploy was less interactive than I would've liked. Can we pipe the output from the hosting / functions or put our own spinner / progress indicator?

Thanks for the review! I'll address some of the comments later this week. I'll probably not find the time for everything we discussed last week, but it shouldn't be a blocker for 6.0.0.

@jamesdaniels I did a few improvements:

• Node.js version check - basically, we verify if the local node version satisfies ^10.0.0
• Added --preview flag
• Now we're using the versions from package.json as you suggested

@mgechev @jamesdaniels hey thanks for the great work!

I run ng add @angular/fire for an angular universal project (here's the result commit michelepatrassi/ng-starter@370526c) and I cannot grasp two changes:

• added devDependencies like inquirer, open, firebase-admin...why my main project would ever need them? Firebase functions are in a subfolder usually, and all dependencies are installed there
• the externalDependencies meaning for my server app with all the firebase stuff

What are these changes solving? Does the second one maybe solves something like the externals filter done here https://gist.github.com/michelepatrassi/242f1f0a867af99918977ea64787fcee#file-webpack-server-config-js ?