Unfortunately, this particular setup does not seem to play nicely with the Forge CLI which fails at the linting stage with something like:
Error: "parserOptions.project" has been set for @typescript-eslint/parser.
The file does not match your project config: src/main.ts.
The file must be included in at least one of the projects provided.
It seems the error happens because the Forge linter picks the tsconfig.json file by default. If I remove project references in the tsconfig.json and merge the contents from tsconfig.app.json into the file the Forge linter works as expected.
If there was an option to tell the Forge CLI which tsconfig.json it should use, I believe this issue would be resolved.
Btw, for forge deploy I am currently working around this limitation by using the --no-verify option. However, forge tunnel does not seem to have an option to disable the linting stage which is a major pain point when trying to achieve an efficient dev loop.
Thank you for reaching out. We understood the problem have created a ticket for this issue and will bring it up with the team to check on the prioritisation. Thank you for your patience and understanding.
Thanks for picking this up and having a look. I ran into this issue when I tried to find a Forge app set up using a monorepo project structure. In this particular case, I tried to used Nx which generated a Typescript project using project references.
I was considering the renaming approach, however, I do not think this will work because none of the tsconfig files are complete on their own (see my initial post for an example of the base tsconfig file - note that this is the file called tsconfig.json). Renaming will likely also not play nicely with the Nx tooling/CLI as it relies on a certain project structure to work.
Unfortunately, I did not properly keep track of my changes when I tried this out because it was just a first quick test. So I do not have the initial state with project references anymore.
Having said that, to us, it is not super important to solve this specific problem. Instead, we would much prefer if Atlassian would support a Forge project structure that plays nicely with custom UI and Typescript. I have summarized some of our requirements in the README of another attempt we made using Turborepo (unfortunately, we ran into issues there as well).
For us, the ideal situation here would be if Atlassian supports a specific project setup that supports easy building, tunneling, and deployment of Forge custom UI apps using Typescript. Many modern frameworks out there (most prominently Angular) work with a specific project structure which allows them to provide great developer tooling. Additionally, as a developer, it allows me to bootstrap a project within a matter of seconds without having to think of where to put my files, which tooling to use, or scripts to write to build it. I feel, the existing Forge project structure was sufficient for simple sample apps using Forge UI, however, it does not scale well to more complex projects using custom UI and Typescript.
I hope this gives you a better understanding of what we were looking for when we ran into the issue described in this thread.