Working with multiple Fonto Editor instances and multiple Fonto Development Tools (FDT) installations? In this blog post, we explain how to manage each editor with its own SDK version and matching tools setup.

When a developer works on a single instance of Fonto Editor, it’s just one editor running on a specific SDK version. However, many implementation partners manage multiple instances, each using a different SDK version. Since the Fonto Development Tools (FDT) must match the SDK version of the editor, and related products, you’re working on, running multiple versions in parallel can lead to conflicting versions and tedious switching between versions of our tooling. This blog post explains the difference between global and local installations of our tooling and provides a step-by-step guide for setting up a multi-version development environment, enabling you to manage multiple editor and related product instances efficiently.

Global installation

When working on a single instance of Fonto Editor, let’s say 8.14.0, it’s easiest to just simply install the Fonto Development Tools globally using:

npm install --global @fontoxml/fontoxml-development-tools@8.14.0

Installing version 8.14.0 of our tooling globally allows you to create or maintain a single editor instance that runs on that specific version on your development machine.

Because our tooling follows a “lock-step” versioning model—where the tooling version must match the editor and all related products—upgrading to 8.14.1 requires installing the corresponding tooling globally and updating the editor and all related products to the same version.

npm install --global @fontoxml/fontoxml-development-tools@8.14.1

But here’s where it gets tricky. Let’s suppose you also have another editor running on version 8.13.0 and want to upgrade it to 8.13.1. Your global installation of 8.14.1 will work for the original editor, but attempting to use it for the 8.13.1 upgrade will result in a version mismatch warning. To avoid this problem, we recommend using a local installation.

Local installation

As discussed in the previous chapter, relying on a globally installed version of our tooling can cause problems when working with multiple Fonto Editor instances. Manually switching versions is time-consuming and increases the risk of version mismatches or worse, build errors!

A better approach is to use local installations of our tooling. By now, you have Node.js installed and are familiar with npm. But to take full advantage of local tooling, or rather project specific tooling, it’s worth understanding how npx can improve your workflow.

npx is a package runner that comes with npm (v5.2.0 and later). It allows you to execute packages without installing them globally. Here’s how it works:

• If the package exists locally in node_modules, npx runs the local version.
• If it doesn’t, npx temporarily downloads the package, runs it, and then removes it—keeping your global environment clean.

This makes it easy to run one-off commands or project-specific tools without relying on global installs. But as a Fonto developer, this command is here to stay and is not a one-off command.

When creating a new editor instance, a package.json file is generated in the editor root directory. This file is key for pinning tooling versions locally.

At the time of writing, the following package.json is created automatically:

{
	"devDependencies": {
		"typescript": "4.3.4"
	}
}

For example, in your 8.14.0 editor instance, you can install the development tools locally like this:

npm install --save-exact @fontoxml/fontoxml-development-tools@8.14.0

Here, --save-exact ensures the package is added to devDependencies in package.json, for specifically that version, replacing the need for a global install. This guarantees that every developer working on the project uses the exact same version, avoiding conflicts and manual version management after running npm install.

You’ll notice that the package.json has been updated:

{
	"devDependencies": {
		"@fontoxml/fontoxml-development-tools": "8.14.0",
		"typescript": "4.3.4"
	}
}

But what now… fdt isn’t registered globally. How do I use it? The answer is simple, we use npx!

test-8.14.0> npx fdt

Subarashii! You’ll see the command runs successfully even though it’s not installed globally. It’s executed from the local installation, pinned to the exact version of the editor you’re working with.

In another project, where you have the following:

{
	"devDependencies": {
		"@fontoxml/fontoxml-development-tools": "8.13.0",
		"typescript": "4.3.4"
	}
}

Running the same command after running npm install:

test-8.13.0> npx fdt

Our tooling will then display 8.13.0 as its version.

That’s it! You now have a multi-version development machine which makes switching between editor versions and our tooling effortless.

Final touches to your projects

Since we’re using npx to start our editor instances, we can make this process even easier. The Node.js ecosystem provides built-in functionality to simplify it further.

You’ve seen the package.json in the previous chapter. Let’s add something new.

The scripts property in a package.json file allows you to define custom commands that can be run using npm. Each ‘script’ is associated with a command that can be executed in the terminal, making it easier to automate tasks such as starting a server, running tests, or building your project. For example, you can define a script like "start": "npx fdt editor run" and then run it with the command npm start.

Update it to the following:

{
	"devDependencies": {
		"@fontoxml/fontoxml-development-tools": "8.14.0",
		"typescript": "4.3.4"
	},
	"scripts": {
		"build": "npx fdt editor build",
		"start": "npx fdt editor run"
	}
}

Running npm start will launch the editor using the locally installed version, and npm run build will build the editor using the same local version.

This approach simplifies instructions for developers, ensures that each editor instance uses the correct version, and avoids the overhead and potential conflicts associated with globally installed tooling. It’s a more reliable workflow for managing multiple editor instances.

Above and beyond

Ready to take this a step further? Is that even possible? Yes, let’s go for it.

This approach can be applied to all our products as well. The following example is experimental and uses concurrently, but it has proven to be a reliable, cross-platform way to start and update our entire product stack when working in a development environment.

Let’s get crazy…

{
	"scripts": {
		"all": "npx concurrently 'npm:start:*(!dist)'",
		"all-dist": "npx concurrently 'npm:start:*(!dev)'",
		"build": "npx fdt run build",
		"postinstall": "npx fdt editor upgrade --non-interactive",
		"start": "npx fdt editor run",
		"start:content-quality": "npx fdt content-quality run --location ./apps/content-quality",
		"start:document-history": "npx fdt document-history run --location ./apps/document-history",
		"start:editor:dev": "npx fdt editor run",
		"start:editor:dist": "npx fdt editor run --dist",
		"start:output": "npx fdt output run --location ./apps/output",
		"start:review": "npx fdt review run --location ./apps/review",
		"upgrade": "npx concurrently 'npm:upgrade:*'",
		"upgrade:content-quality": "npx fdt content-quality upgrade --non-interactive --location ./apps/content-quality",
		"upgrade:document-history": "npx fdt document-history upgrade --non-interactive --location ./apps/document-history",
		"upgrade:editor": "npx fdt editor upgrade --non-interactive",
		"upgrade:output": "npx fdt output upgrade --non-interactive --location ./apps/output",
		"upgrade:review": "npx fdt review upgrade --non-interactive --location ./apps/review"
	}
}

Summary of the commands:

• npm install
  Installs all project dependencies listed in package.json.
• npm run build
  Builds the editor and outputs the compiled files to the dist directory.
• npm run all
  Starts the entire product stack in development mode, running all services concurrently.
• npm run all-dist
  Starts the entire product stack using the compiled editor from the dist directory, rather than the development version and starts all related products.
• npm run upgrade
  Updates all products to the versions specified for your tooling in your devDependencies, ensuring consistency across the stack.

Conclusion

In summary, Fonto’s tooling and workflow are designed to make managing multiple editor instances and products straightforward. Using local installations, pinned versions, and npm (scripts) ensures you, as a developer, can seamlessly work on multiple editors and related products.

If you have any questions or topics you’d like us to focus on, our support team is always ready to help. You can reach out by filing a support ticket, and feel free to reference this blog post in case you have any further questions about streamlining your development process.