Skip to Content
We're building a full JS ecosystem for Unity, with OneJS at the core (open source release soon 🚀). Also cooking up a bunch of pre-made game UIs, plus a big site revamp in progress.

In the default OneJS workflow, tsc compiles your TypeScript files into @outputs/tsc, and then esbuild takes over to bundle everything into a single file at @outputs/esbuild/app.js.

Our esbuild setup mainly handles two things: import transformation and asset copying for OneJS-specific npm packages.

Import Transformation

Thanks to PuerTS, you can access .NET types from JavaScript using the CS. namespace. OneJS builds on that by automatically transforming certain import statements to use the CS. namespace too.

Most JS module names are lowercase, so we use capitalization as a cue. If you import a module with a capitalized name like MyModule, we’ll treat it as a .NET type and it gets auto-transformed to CS.MyModule. This behavior comes from the importTransformationPlugin defined in esbuild.config.js.

It’s mainly for convenience, but you’re free to tweak or remove the plugin from esbuild.mjs if you prefer a different convention.

Asset Copying

The copyAssetsPlugin handles syncing assets from npm packages that include their own asset folders. This makes it easier to build reusable OneJS packages.

For example, the fortnite-sample package includes a onejs.assets-path field in its package.json. This tells the plugin where to find the package’s assets, so they can be copied into the consuming project’s assets folder.

fortnite-package.json
"onejs": { "assets-path": "resources" }

This setup helps keep assets organized and makes package development more plug-and-play. For example, all you have to do to use the fortnite-sample package is running npm install fortnite-sample.