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.

2 Likes
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] - 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
11

Same issue here, I see the ticket is getting stalled. Can we get an update on if this is currently being worked on?

12

I ran into this issue too using a NX monorepo and forge CLI.
I managed to get it working by slightly changing the setup in my Forge app. By default, NX sets up applications in the repo with 3 tsconfig files:

  • tsconfig.app.json - Typescript config for the application code (this is the desired config for use when bundling a forge application).
  • tsconfig.spec.json - Typescript config for tests
  • tsconfig.json - Whole app Typescript config, incorporating both the app and spec configs.

In my Forge app, I changed this slightly so that the Whole app config was called tsconfig.all.json and the application code’s config is tsconfig.json. This required a small tweak to the root tsconfig that references these to point to the tsconfig.all.json file for the forge application, but after that the monorepo setup worked nicely with the forge CLI.

13

Since this issue is still being discussed, I wanted to provide an update on where we stand with this today.

We concluded that the Forge CLI should not do Typescript compilation. Instead, we compile the TS ourselves and hand JS to the Forge CLI since that’s what’s executed.

To support this process, we built nx-forge to assist with the compilation, packaging and deployment of the Forge apps.

@ryan.brown The above approach solved all the Forge CLI Typescript quirks for us, and we generally work with the generated Nx setup without modifications.

1 Like