Adding proof-of-concept for sourcing frameworks docs here in GH (#5637)

* Adding Angular guide and include files.
* Adding README for frameworks docs.
* Going ahead and adding Express and Next.js guides as well.
* Formatting

---------

Co-authored-by: James Daniels <jamesdaniels@google.com>

src/frameworks/docs/README.md

@@ -0,0 +1,86 @@
+# Web frameworks docs on firebase.google.com
+
+This directory contains the source of the Web frameworks documentation on
+https://firebase.google.com/docs/.
+
+We welcome your contributions! See [`CONTRIBUTING.md`](../CONTRIBUTING.md) for general
+guidelines.
+
+This file has some information on how our documentation is organized and some
+non-standard extensions we use.
+
+## Standalone files vs. page fragments
+
+There are two kinds of source file for our docs:
+
+- **Standalone files** map one-to-one to a single page on firebase.google.com.
+  These files are mostly-standard Markdown with filenames that correspond with
+  the URL at which they're eventually published.
+
+  Standalone pages must have filenames that don't begin with an
+  underscore (`_`). For example, `angular.md` in this folder is
+  a standalone file.
+
+- **Page fragments** are included in other pages. We use page fragments either
+  to include common text in multiple pages or to help organize large pages.
+  Like standalone files, page fragments are also mostly-standard Markdown, but
+  their filenames often don't correspond with the URL at which they're
+  eventually published.
+
+  Page fragments almost always have filenames that begin with an underscore
+  (`_`). For example, `_before-you-begin.md` is a file of standard steps that
+  should be included in all frameworks integration guides in this folder.
+
+## Non-standard Markdown
+
+### File includes
+
+> Probably not useful to you as a contributor, but documented FYI.
+> We use double angle brackets to include content from another file:
+
+```
+<<path/to/file>>
+```
+
+Note that the path is based on our internal directory structure, and not the
+layout on GitHub. Also note that we sometimes use this to include non-Web frameworks
+related content that's not on GitHub.
+
+### Page metadata
+
+> Probably not useful to you as a contributor, but documented FYI.
+> Every standalone page begins with the following header:
+
+```
+Project: /docs/_project.yaml
+Book: /docs/_book.yaml
+```
+
+These are non-standard metadata declarations used by our internal publishing
+system. There's nothing you can really do with this, but it has to be on every
+standalone page.
+
+### Getting started writing
+
+Unless the needs of your framework are radically different, you should
+follow the outline and example presented in `angular.md`, which to date is
+the most completely fleshed-out integration. Details for your framework are
+likely to be different, but the overall outline should probably be similar.
+
+Firebase follows the [Google developer documentation style guide](https://developers.google.com/style),
+which you should read before writing substantial contributions.
+
+Footer
+© 2023 GitHub, Inc.
+Footer navigation
+Terms
+Privacy
+Security
+Status
+Docs
+Contact GitHub
+Pricing
+API
+Training
+Blog
+About

src/frameworks/docs/_includes/_before-you-begin.md

@@ -0,0 +1,10 @@
+## Before you begin
+
+Before you get started deploying your app to Firebase,
+review the following requirements and options:
+
+- {{firebase_cli}} version 11.14.2 or later. Make sure to
+  [install the {{cli}}](/docs/cli#install_the_firebase_cli)
+  using your preferred method.
+- Optional: Billing enabled on your Firebase project
+  (required if you plan to use SSR)

src/frameworks/docs/_includes/_initialize-firebase.md

@@ -0,0 +1,12 @@
+## Initialize Firebase
+
+To get started, initialize Firebase for your framework project.
+Use the {{firebase_cli}} for a new project, or modify `firebase.json` for an
+existing project.
+
+### Initialize a new project
+
+1. In the {{firebase_cli}}, enable the web frameworks preview:
+   <pre class="devsite-terminal">firebase experiments:enable webframeworks</pre>
+1. Run the initialization command from the {{cli}} and then follow the prompts:
+   <pre class="devsite-terminal">firebase init hosting</pre>

src/frameworks/docs/_includes/_preview-disclaimer.md

@@ -0,0 +1,4 @@
+Note: Framework-aware {{hosting}} is an early public preview. This means
+that the functionality might change in backward-incompatible ways. A preview
+release is not subject to any SLA or deprecation policy and may receive limited
+or no support.

src/frameworks/docs/angular.md

@@ -0,0 +1,170 @@
+Project: /docs/hosting/\_project.yaml
+Book: /docs/\_book.yaml
+page_type: guide
+
+{% include "_shared/apis/console/_local_variables.html" %}
+{% include "_local_variables.html" %}
+{% include "docs/hosting/_local_variables.html" %}
+
+<link rel="stylesheet" type="text/css" href="/styles/docs.css" />
+
+# Integrate Angular Universal
+
+With the Firebase framework-aware {{cli}}, you can deploy your Angular application
+to Firebase and serve dynamic content to your users.
+
+<<\_includes/\_preview-disclaimer.md>>
+
+<<\_includes/\_before-you-begin.md>>
+
+- Optional: AngularFire
+
+<<\_includes/\_initialize-firebase.md>>
+
+1. Choose your hosting source directory; this could be an existing Angular app.
+1. Choose "Dynamic web hosting with web framework."
+1. Choose Angular.
+
+### Initialize an existing project
+
+Change your hosting config in `firebase.json` to have a `source` option, rather
+than a `public` option. For example:
+
+```json
+{
+  "hosting": {
+    "source": "./path-to-your-angular-workspace"
+  }
+}
+```
+
+## Serve static content
+
+After initializing Firebase, you can serve static content with the standard
+deployment command:
+
+```shell
+firebase deploy
+```
+
+## Pre-render dynamic content
+
+To prerender dynamic content in Angular, you need to set up Angular Universal.
+The {{firebase_cli}} expects Express Engine:
+
+```shell
+ng add @nguniversal/express-engine
+```
+
+See the [Angular Universal guide](https://angular.io/guide/universal)
+for more information.
+
+### Add prerender URLs
+
+By default, only the root directory will be prerendered. You can add additional
+routes by locating the prerender step in `angular.json` and adding more routes:
+
+```json
+{
+  "prerender": {
+    "builder": "@nguniversal/builders:prerender",
+    "options": {
+      "routes": ["/", "ANOTHER_ROUTE", "AND_ANOTHER"]
+    },
+    "configurations": {
+      /* ... */
+    },
+    "defaultConfiguration": "production"
+  }
+}
+```
+
+Firebase also respects `guessRoutes` or a `routes.txt` file in the hosting root,
+if you need to customize further. See [Angular’s prerendering
+guide](https://angular.io/guide/prerendering) for more information on those
+options.
+
+### Optional: add a server module
+
+#### Deploy
+
+When you deploy with `firebase deploy`, Firebase builds your browser bundle,
+your server bundle, and prerenders the application. These elements are deployed
+to {{hosting}} and {{cloud_functions_full}}.
+
+#### Custom deploy
+
+The {{firebase_cli}} assumes that you have server, build, and prerender steps in
+your schematics with a production configuration.
+
+If you want to tailor the {{cli}}'s assumptions, configure `ng deploy` and edit the
+configuration in `angular.json`. For example, you could disable SSR and serve
+pre-rendered content exclusively by removing `serverTarget`:
+
+```json
+{
+  "deploy": {
+    "builder": "@angular/fire:deploy",
+    "options": {
+      "browserTarget": "app:build:production",
+      "serverTarget": "app:server:production",
+      "prerenderTarget": "app:prerender:production"
+    }
+  }
+}
+```
+
+### Optional: integrate with the Firebase JS SDK
+
+When including Firebase JS SDK methods in both server and client bundles, guard
+against runtime errors by checking `isSupported()` before using the product.
+Not all products are [supported in all environments](/docs/web/environments-js-sdk#other_environments).
+
+Tip: consider using AngularFire, which does this for you automatically.
+
+### Optional: integrate with the Firebase Admin SDK
+
+Admin bundles will fail if they are included in your browser build, so consider
+providing them in your server module and injecting as an optional dependency:
+
+```typescript
+// your-component.ts
+import type { app } from 'firebase-admin';
+import { FIREBASE_ADMIN } from '../app.module';
+
+@Component({...})
+export class YourComponent {
+
+  constructor(@Optional() @Inject(FIREBASE_ADMIN) admin: app.App) {
+    ...
+  }
+}
+
+// app.server.module.ts
+import * as admin from 'firebase-admin';
+import { FIREBASE_ADMIN } from './app.module';
+
+@NgModule({
+  …
+  providers: [
+    …
+    { provide: FIREBASE_ADMIN, useFactory: () => admin.apps[0] || admin.initializeApp() }
+  ],
+})
+export class AppServerModule {}
+
+// app.module.ts
+import type { app } from 'firebase-admin';
+
+export const FIREBASE_ADMIN = new InjectionToken<app.App>('firebase-admin');
+```
+
+## Serve fully dynamic content with SSR
+
+### Optional: integrate with Firebase Authentication
+
+The web framework-aware Firebase deployment tooling automatically keeps client
+and server state in sync using cookies. The Express `res.locals` object will
+optionally contain an authenticated Firebase App instance (`firebaseApp`) and
+the currently signed in user (`currentUser`). This can be injected into your
+module via the REQUEST token (exported from @nguniversal/express-engine/tokens).