We are using a custom packaging solution based on Nx Forge, which takes the stance that Forge should be treated as a JS/Node execution environment and, as such, should only be handed JS.
nx-forge, together with the tooling of your choice, produces Forge app bundles into an output directory that are accepted by the Forge CLI. Any CLI command is then run from the output directory.
As already mentioned a few times, bundlers do not like producing output in a src directory, and getting rid of this constraint and accepting bundle output from a manifest-defined location would be a welcome improvement, making integration with bundlers generally easier.
Overall, this approach looks good to me, and I appreciate the direction to:
formalize a contract for pre-built Forge apps
provide defined source-map support
eliminate double-bundling
Regarding dependencies, Forge simply uploading the contents of a target directory unchanged appears to be the cleanest solution, letting developers assemble its contents. This may require a bit more work on the configuration side, but I think it ultimately provides the flexibility we are looking for with this solution.
We currently use Vite to build our Custom UI frontend (with Vite dev server + forge tunnel for local development), while our backend functions and UI Kit modules rely on the built-in Forge bundling.
Overall I like the idea of owning the build process at all levels. We’re not currently blocked by the Forge bundler, but I can see how BYOB would benefit us.
I’d like to +1 the points already raised about like Source map support and ES module output.
Thank you for the robust engagement in this RFC and the quality of feedback you provided. Your comments gave us a lot to think about.
We’re now closing RFC-139 to further feedback.
What did we hear?
We heard that there is demand for a solution to this problem. Even developers who have already built their own workarounds would appreciate some improvements, such as no longer having to force their bundler/packager to build outputs to the `src/` directory.
When it comes to dependency management, the general desire is for Forge to leave `node_modules/` alone and not perform any processing or filtering of its contents, including file types like `.node` and `.wasm`.
We heard clearly that source maps need to be passed through unadulterated in order to ensure the runtime artifact generates useful stack traces.
There is desire for the bundling & packaging process to become even more decoupled: removing the requirement to use the Forge CLI or make changes to the manifest at all. We agree that in the long term we want to align building Forge apps with standard ways of working. However, removing the Forge CLI from the deployment flow is a significantly broader change as it requires changes to the API contract between the Forge CLI and the Forge platform services. We’re not going to tackle it as part of the initial work on the BYO bundler, but will consider how we open this up further in the future.
What did we change?
We heard feedback that ESM module syntax is strongly preferred to CommonJS. We did not scope this initially as it is a bigger change that also requires changes to the Forge runtime environment (not just the CLI). It won’t be in our initial release, but we agree this would be a valuable enhancement and will prioritise how and when we can include this as a subsequent milestone.
Thank you for flagging that there is no documentation for the `FORGE_INSPECT_ARCHIVE` magic environment variable. We agree that it would be good to formally support this debugging option as a flag in the Forge CLI. This should also support a ‘local build only’ option to inspect the build output without uploading. This has been moved into our product backlog as a potential short term improvement. If we can’t ship a quick improvement for this, I will also ensure we publish documentation about this flag so that at the very least, it is more discoverable in the future.
There was a thread of discussion about the related challenge of dealing with the inflexibility of the hard-coded location of the Forge `manifest.yml`, which is also a pain point for using external bundlers/packagers. Again as above, we think this might be solvable in the short term. We’ll see if we can also tackle this problem in our solution, but it may become a future enhancement depending on effort to solve.
What is coming next?
We are preparing for an early access release of the proposed functionality next month (August 2026), which will be available as an experiment Forge CLI version. Keep an eye on the Forge developer changelog for further information.
This didn’t come up directly in the discussion, but I wanted to clearly reiterate that our “Bring Your Own Bundler (BYOB)” plans are for an optional, additional feature for app developers who want the additional flexibility. There are no plans to remove support for the built-in bundler or de-prioritise work to keep it modern and up-to-date.