Document must have at least 1 module (valid-module-required)

Thanks @jhazelwood .

re: documentation, here’s some quick ones off the top of my head:

  • As noted, references connect-to-forge@latest. Should be @atlassian/connect-to-forge@latest.
  • Mentions that “Your Forge app now has three environments by default: development, staging, and production, and each should have its own Connect key. There is no automated way (yet) of handling these.” (and links to an example deploy.js script as a possible workaround).
    I have seen community posts where people seem to be using manifest environment variables (e.g. key: ${APP_CONNECT_KEY}) - although it is unclear if that actuallyworks or not. If that is a viable approach, maybe mention it in the docs?
  • It would be good to understand the implications of NOT using different app.connect.key values across different environments.
    In our case, our Connect app uses one key and we deploy to different dev / staging / prod instances. Given that app.conect.key should match the Connect key in order properly take over the existing Connect app (and we would want to test this in dev & staging), it is somewhat unclear whether we do truly need different keys for each environment, or whether that’s just a suggestion?
  • The section that documents app.connect includes key and remote properties, but not authentication: jwt (which is part of the generated manifest that connect-to-forge produces).
    I couldn’t find anywhere that describes exactly what authentication: jwt means (but from community posts it seems like it just refers to how the connect app authenticates with the host product). It should be included in the manifest reference.
  • The page that documents permission.scopes doesn’t mention anything about Connect scopes (e.g. read:connect-jira, write:connect-jira etc.).
    Once again, community posts help understand what these are, but they should really be documented in the reference docs.
  • The connectModules section has no documentation at all. It just reads “A list of the Connect modules used by the app”.
    Its great that the connect-to-forge tool migrates these over, and looking at them it seems (for the most part) that these are are identical to how they’re defined in Connect, just represented as YAML instead of JSON. The exception is jira:lifecycle which, if it weren’t for the connect-to-forge tool, it is unclear where someone go to learn how to define lifecycle hooks for a Connect-on-Forge app? Maybe it is documented, but I couldn’t find it.
  • As mentioned, the section for modules in the reference indicates that this field is required; but as per your comment above, that doesn’t seem to be the case?

Another thing, that is technically not a documentation issue, but could perhaps be made a bit clearer is in relation to manifest variables, which I asked about here: