Hi Forge team,
Is there any supported mechanism planned for using an alternate version of TypeScript? I have an existing codebase running on TS 4.4 that I am trying to get to build on Forge, but it is…not easy. I was able to hack it into a working state, but I wouldn’t want to ship anything with this amount of duct tape.
This creates a blocker for anyone who has a project built with a newer version of TS than yours, but who cannot (or doesn’t want to) backport the entire project syntax to an earlier version of TS.
I was able to hack this by replacing the TypeScript versions used in the package.json for @forge/{bundler,cli,cli-shared,tunnel}, referencing those directories as local packages from my own project’s package.json, and then running “./node_modules/.bin/forge tunnel” instead of using the globally-installed “forge” command. This was not entirely straightforward because the source for these @forge/* packages does not seem to be published anywhere (could this be done?).
Ask #1: What about the idea of moving to (say) peer dependencies of typescript (and @typescript-eslint) in all @forge packages, or some other mechanism of your choice, so that we can bring whatever version of typescript we want?
After doing this, I thought I had everything working, but then I found that “forge tunnel” didn’t work, since it turns out that “tunnel” actually compiles in the container (rather than on the host) and it has its own version of typescript baked into the Docker image.
I was finally able to get this to work after I discovered the “dev mode” for Forge Tunnel, which allows you to replace the /tunnel/node_modules directory in the container by invoking it like this:
# Copy the existing image's public tag and name it according to what the dev mode expects
docker tag atlassian/forge-tunnel:latest local/forge-tunnel:test
# Run the old version of the tunnel for reference, grab its node_modules, and stop the tunnel
forge tunnel &
mkdir -p ../forge-tunnel/hardcopied_node_modules
docker cp forge-tunnel-docker:/tunnel/node_modules ../forge-tunnel/hardcopied_node_modules
kill %1
# Now replace ../forge-tunnel/hardcopied_node_modules/node_modules/typescript
# with the version you need
# Start the tunnel in dev mode, which will mount ../forge-tunnel/hardcopied_node_modules/node_modules into /tunnel/node_modules
FORGE_DEV_DOCKER_TUNNEL=true ./node_modules/.bin/forge tunnel
Ask #2: The above method for “forge tunnel” is particularly hacktastic. Can you publish the build source for the Docker image somewhere? Even better, the perfect solution would allow us to provide (say) some sort of command-line parameter to “forge tunnel” that could be passed as a series of packages and versions to “npm install” in the container, which would get run the first time the container is started? And/or allow us to specify our own custom startup script that is run before starting the tunnel?
Ask #3: While on the subject of porting real apps to Forge, we need the ability to provide an explicit path/filename for tsconfig.json, as well as an option to override or append arbitrary properties into the final webpack configuration (perhaps let us supply a config transformer?). For example, our project uses aliases for module resolution (eg. ‘import “Foo/test”’ instead of ‘import “…/…/…/services/foo/test”’) and this doesn’t seem to work at all with your hardcoded webpack config.
Ask #4: Could there be a way to specify full paths for the function handler entrypoints in the manifest.yml? It looks like we are forced to dump every single entrypoint into the top-level “src” directory. This is presumably fine for simple apps, but less so for complex projects that are built for multiple environments (of which Forge is just one).
Thanks!
Scott