Forge typescript support - absolute path imports (compilerOption rootDir)

Forge
1

I have rewritten Forge app to typescript and I was trying to set up absolute path imports (from root) with tsconfig

{
    "compilerOptions": {
        "rootDir": "./src",
        "baseUrl": "./src",
        ...
    }
    ...
}

I get no errors or warnings in editor but once i run forge deploy, it crashes on invalid import so I was wondering if anyone of you tried it and if there is some workaround or it is impossible and would be Feature Request on atlassian

1 Like
2

Hi,

If you don’t mind, what are you trying to achieve by enabling absolute path imports? The deploy step shouldn’t produce a broken application without complaining, but I’m curious to see if there’s a use case for this.

Can you please show a (cut down) example of a failing app?

3

Hi, thanks for the response. So basically, I have file structure for customfield type Forge App like this:

.
├── package.json
├── src
│    ├── api
|    |    ├── issue.ts (function getAllJqlResults)
|    |    ├── customfield.ts
|    |    └── logger.ts
│    ├── index.tsx
│    └── screens
|          └── edit
|                └── App.tsx (<-- trying to import getAllJqlResults)
└── tsconfig.json

and when I am in ./src/screens/edit/App.tsx I wanted to be able to import my api calls from ./src/api module (with previously mentioned tsconfig import should looks like this)

import getAllJqlResults from "api/issue"

but that throws this error (running: forge deploy --verbose)

ℹ Packaging app files

Error: Bundling failed: Module not found: Error: Can't resolve 'api/issue' in '/Users/____/csas/code/forge/jira-customfields/src/screens/edit'

Error: Bundling failed: Module not found: Error: Can't resolve 'api/issue' in '/Users/____/csas/code/forge/jira-customfields/src/screens/edit'
    at RuntimeBundler.bundle (/opt/homebrew/lib/node_modules/@forge/cli/out/deploy/packager/runtime-bundler.js:27:23)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async AppPackager.package (/opt/homebrew/lib/node_modules/@forge/cli/out/deploy/packager/packager.js:16:31)
    at async PackageUploadDeployCommand.execute (/opt/homebrew/lib/node_modules/@forge/cli/out/deploy/package-upload-deploy.js:14:76)
    at async CommandLineUI.displayProgress (/opt/homebrew/lib/node_modules/@forge/cli/node_modules/@forge/cli-shared/out/ui/command-line-ui.js:46:28)
    at async DeployView.reportDeploymentProgress (/opt/homebrew/lib/node_modules/@forge/cli/out/command-line/view/deploy-view.js:54:24)
    at async DeployController.run (/opt/homebrew/lib/node_modules/@forge/cli/out/command-line/controller/deploy-controller.js:129:27)
    at async Command.actionProcessor (/opt/homebrew/lib/node_modules/@forge/cli/out/command-line/command.js:93:32)
    at async Promise.all (index 0)
    at async Command.parse (/opt/homebrew/lib/node_modules/@forge/cli/out/command-line/command.js:196:13)
    at async main (/opt/homebrew/lib/node_modules/@forge/cli/out/command-line/index.js:57:5)

but when I change it to relative import

import getAllJqlResults from "../../api/issue"

then there are no problems

4

Thanks for the explanation!

Your Forge application runs in a special runtime environment Atlassian maintains. Forge CLI uses Webpack internally to bundle your application, and unfortunately our configuration seems to be incompatible with the absolute paths configuration.

I suggest either (in order of preference):

  • Leaving the relative references in your code - this is common in JavaScript/TypeScript projects
  • Pulling some functionality into proper Node modules and referencing them in your package.json - this will let you import them per Node conventions (e.g. import { fetch } from '@forge/api')
  • Or if you aren’t satisfied with our bundling altogether, run a pre-build step to bundle your application into a single file, put that in src/index.js and use forge deploy afterwards.
1 Like
5

Do you plan to tune forge bundling to understand rootDir/baseUrl in foreseeable future?

6

No plans that I know of to support these options specifically. We are running an EAP that removes the need for Webpack on the backend though. It might not suit you if you want to customise the app’s directory structure, but we already have feedback there about the need to support more flexible bundle/compilation.