feat(nuxt): enable appManifest by default

[danielroe]

🔗 Linked issue

#21641

❓ Type of change

• 📖 Documentation (updates to the documentation, readme or JSdoc annotations)
• 🐞 Bug fix (a non-breaking change that fixes an issue)
• 👌 Enhancement (improving an existing functionality like performance)
• ✨ New feature (a non-breaking change that adds functionality)
• 🧹 Chore (updates to the build process or auxiliary tools and libraries)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

This follows up on #21641 to enable app manifests and client-side routeRules by default. This can be disabled by setting experimental.appManifest to false.

📝 Checklist

• I have linked an issue or discussion.
• I have updated the documentation accordingly.

[stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[Atinux]

yes 💯

This is a great improvement

[pi0]

💯

Before making it public available, it would be nice if we add "nuxtManifestVersion": "1" to the generated manifests/latest to make sure for forward compatibility. (we can omit and implicitly consider undefined as v1 but well that's less secure to distinguish from invalid JSON responses)

[danielroe]

@pi0 Any reason you propose nuxtManifestVersion rather than version? I ask because I would be inclined to choose the latter. The fact that it's Nuxt is clear from the fact it's located inside /_nuxt/.

[pi0]

I initially wrote version and then edited it to nuxtManifestVersion actually. The reason and main point of this field is that, we make sure we are fetching a valid and predictable JSON, interpreting it as nuxt manifest. While it is within _nuxt directory, webserver might serve a wrongly JSON file that only consists version in it -- as placeholder. Another reason is that, we might use version as actual build-version (while nuxtManifestVersion describes the JSON schema's version and format not user version so we reserve for that)

Update: Genric version key can be conflicting with nitro manifest handling. I clearly communicated that nuxtVersion field is a safer option.

[danielroe]

To explain a bit further, I don't want to call the version field nuxtVersion as it's a Nuxt manifest already and located in the Nuxt (client) build directory.

If you are worried about the version key conflicting I am happy to rename it. Options include manifestVersion or v or directly using $schema with a fully resolved JSON schema (which I have already written).

However, honestly I feel like we're over-engineering this as there is no nitro client manifest in existence at the moment, and it's not clear to me why it would conflict with the nuxt manifest if it did exist. (Presumably when/if nitro manifest is introduced we will be able to keep them separate as the nuxt manifest path is totally within nuxt's control.)

[pi0]

For full context, the client build manifest integrating with route rules was always meant to be implemented in Nitro upstream. You decided to move it forward this way, and we agreed to make sure these will be forward-compatible (which addition of a single field is not IMO constant with this vision)

For a truly universal build manifest, it needs to be extendable. It means it is not dedicated to Nitro or even Nuxt (modules, integrations, and providers like edgio client might need to extend it as well). And because of this, the contents of this file shall be multi-versioned when versioning matters, also namespace when there are framework specific features to avoid conflicts. We can use a version field such as versions: { nitro, nuxt, ... }.

The fact that this file is generated today in buildDir (default: /_nuxt/) is not enough to know this is a nuxt-generated artifact. When at some point we rely on nitro to write the manifest file, it would still be into buildDir (which is hashed and safe for CDN deployments in contrary to ambiguous public/ namespace). When someone also renames buildDir, we cannot universally detect nuxt version anymore.

As also explained before also $schema, is not probably a good addition. This file will be loaded for each page load eventually and a full schmea adds to the bundle + solely schema is not purpose of versioning. Sometime same field, with same name and value type, changes it's behavior by version update (eg: relative url handling)

At this point, i think for sake of Nuxt<>Nitro compatibility, i will move faster forward to implement upstream feature which is not really hard but also ask to not introduce version or v field for now and enable feature if you will, without versionning. Not having any version for now and assume lack of it as v0 is much much safer choice.

[danielroe]

Sounds good to me! We also have a bit of time before v3.8 release so can potentially refactor before then if we have a new nitro feature to play with.

schema

{
  "type": "object",
  "definitions": {
    "MatcherExport": {
      "type": "object",
      "properties": {
        "dynamic": {
          "type": "object",
          "patternProperties": {
            ".*": {
              "$ref": "#/definitions/MatcherExport"
            }
          }
        },
        "wildcard": {
          "type": "object",
          "patternProperties": {
            ".*": {
              "type": "object",
              "properties": {
                "pattern": {
                  "type": "string"
                }
              },
              "required": [
                "pattern"
              ]
            }
          }
        },
        "static": {
          "type": "object",
          "patternProperties": {
            ".*": {
              "type": "object",
              "properties": {
                "pattern": {
                  "type": "string"
                }
              },
              "required": [
                "pattern"
              ]
            }
          }
        }
      },
      "required": [
        "dynamic",
        "wildcard",
        "static"
      ]
    }
  },
  "properties": {
    "version": {
      "type": "number"
    },
    "id": {
      "type": "string"
    },
    "timestamp": {
      "type": "number"
    },
    "matcher": {
      "$ref": "#/definitions/MatcherExport"
    },
    "prerendered": {
      "type": "array",
      "items": {
        "type": "string"
      }
    }
  }
}