Is is possible to specify the `tsconfig` file with the Forge CLI?

Forge Forge Platform and Tools
, , ,
#1

I am trying to set up a Tyepescript-based Forge app that uses project references in the tsconfig.json file to specify a separate app and test/spec config:

{
    "extends": "../../tsconfig.base.json",
    "files": [],
    "include": [],
    "references": [
        {
            "path": "./tsconfig.app.json"
        },
        {
            "path": "./tsconfig.spec.json"
        }
    ],
    "compilerOptions": {
      "baseUrl": "./"
    }
}

In this particular case, I am using NX to generate a node project which generates the three tsconfig files.

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.

2 Likes
#2

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.

#3

Although this does not solve your problem, you might find it helpful to see the following post describing some of the mechanics of how TS is used in the build process (including in “forge tunnel”):

2 Likes
#4

Thank you for sharing that thread, Scott. The points you highlighted made me think that the TS problems may go much further than I initially assumed, in particular with regards to the TS version.

I do hope Atlassian invests some effort into improving Forge TS support and commits to keeping it up to date.

1 Like
#5

Hi @tbinna,
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.

1 Like
#6

Thanks, @LashaniPerera. Is this an internal ticket or is there a public issue we can follow?

#7

@tbinna . Please follow [FRGE-592] Fix forge lint issues when there are multiple tsconfig files with forge app project setup - Ecosystem Jira

2 Likes
#8

@tbinna Would you be able to share the tsconfig* files in your project or a sample repo where we can reproduce the same issue ?

Forge is trying to use the tsconfig file from ${appDirectory}/tsconfig.json location. There could be a workaround for your issue by renaming the right file.

#9

Hey @LashaniPerera

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.

1 Like
#10

@tbinna ,
Thank you for your valuable inputs. I’ll bring this up with the team for further discussions.

2 Likes