Is it possible to have some sort of pre-deploy or post-deploy hook for things like running scripts on compiled code? For example, in order to make custom UI work, sometimes you have to do some editing before deploying. In Next.JS as an example, you have to modify all the relative urls from /_next/ to ./_next/ in order to make everything click in place. To do this, i have to add a package.json script each time to every small custom UI portion i want to use next.js in.
"deploy": "cd frontend && npm run build && cd .. && npm run build-fix && forge deploy",
"build-fix": "find \"dist\" -type f -exec sed -i 's#\"/_next/#\"./_next/#g' {} +"
I would love to see this built in to forge. By no means is this an urgent request, its just a matter of copy pasting the script over to new forge projects but something this useful should just be built in.
Possible Implementation:
A custom webpack plugin that could be ran when everything is complete with the defaults being set as dist or a user could provide it using a forge variable or as an arg to the forge deploy command itself. If you could detect that nextjs is being used and auto enable this hook and provide an option to disable it should the user not want it etc… Apply same logic to other frameworks that need some special handling.
I was curious if anyone was using Next.js inside of Forge apps. Good to know it is at least a thing!
Agreed on the webpack plugin, it is unlikely that they will try supporting other outside frameworks with the focus on Forge UI Kit, but the ability for us to customize for our use case would be helpful.
Welcome to the Atlassian developer community @Zishan!
Interesting idea about “deploy hooks”. But I wonder if the problem isn’t already better solved by monorepo tooling like nx or Turborepo. I say that because the package.json script feels like it proves the Forge CLI already has the right level of composability, and it only suggest the need for composition for the deploy command, not others. Also, the package.json script looks like a suitable solution for simple cases. It seems like that only becomes a problem at the point when other monorepo problems start to creep in. And, maybe a bit of personal bias creeps in against webpack. There’s so much innovation going on in “the bundler” tooling space, that I’d hate to couple the Forge toolchain to webpack (even if, under the hood, it already is).
But all that’s “armchair” opinion of a developer advocate. It’s still a valid feature request. As such, you should know Atlassian doesn’t treat these community topics as official feature requests. Hence, I recommend logging a feature request so you, and others who might stumble upon this thread, would have something formal to track. Could you please open a “suggestion” (our term for feature request) issue yourself in our open Jira (JAC) in the ECO project? Once you have the issue key, please let us know here so other folks can watch, vote, and comment.