We’re revisiting Forge after an aborted attempt many years ago (when the platform was, in our opinion, still too immature to support our use case).
With some of the recent developments such as support for Custom UI macro configs and migration from Connect macros to Forge macros, we’re having another look to assess the viability of migrating.
We are aware that, historically, Forge has been slow to support the latest Typescript versions, and people with complex setups have had to develop all sorts of workarounds.
In our case, we’re developing a Custom UI app that uses Svelte & Typescript, and we have our own webpack-based build that preprocesses our /static/src/* directory and outputs plain old *.{html,js,css} files into a /public directory.
Our manifest then references those build outputs in /public/*, e.g.
resources:
- key: main
path: public/app # /public/app/index.html
- key: macro-config
path: public/editor # /public/editor/index.html
On the backend our @forge/resolver functions are (for now at least) plain old *.js files.
So with a bring-your-own-bundler process for the frontend, and plain JS on the backend, we’re not even using Forge’s built-in support for Typescript at all.
Yet, because we’re using Typescript 5.7.2 and have our own tsconfig.json file in the root of our project, when running forge deploy or forge tunnel (which both internally run forge lint), we get errors and warnings because Forge doesn’t understand some of the configuration in our tsconfig.json file.
(We’re aware of the --no-verify argument for forge deploy, but there’s no such equivalent for forge tunnel that we’re aware of).
One example error is the verbatimModuleSyntax option, which is required by Svelte 4.x:
The TypeScript option verbatimModuleSyntax is now required when using Svelte files with lang=“ts”. Please add it to your tsconfig.json.
…yet when present, Forge complains with:
Error: Unknown compiler option ‘verbatimModuleSyntax’.
Ideally, if Forge isn’t going to allow us to use a more modern TS version + tsconfig.json file any time soon (this issue has been ongoing for numerous years); how about an option to tell Forge “please don’t use Typscript at all”?
While we could (I presume) rename our tsconfig.json file to something else (e.g. tsconfig.ui.json) so that Forge doesn’t use it, we don’t want to (or can’t) do this as our editor and bundling processes are all expecting to find a tsconfig.json file.
At this point (and I should note that the above issue is just one of many reasons), it seems like we will need to shelve our plans for Forge once again, and revisit in another couple of years 
.
