OpenFL for NPM: Explained

[singmajesty]

Hey guys,

We have launched beta versions of OpenFL on NPM, and are rapidly approaching things being stable. Some of you who have been here a while may ask, how does it work? What is it? How it different than the past releases?

NPM is the “Node Package Manager”, but really is a package manager (not unlike Haxelib) for distributing JavaScript packages. Instead of building using the same command-line tools we use for native desktop and mobile, this is a completely different toolset.

However, support for NPM (and support for Haxelib) does not require a separate codebase.

You know that Haxe compiles to many languages, and we take advantage of this to allow OpenFL (traditionally) to compile for many targets. This is all possible, so long as all of your code is written in Haxe. When we target native platforms, we do not go directly to an executable, but generate C++ and build that in another step. NPM and OpenFL is an approach that is not too different, but for the web. Instead of building an output JS file, and calling it a day, we are building to CommonJS modules (used by TypeScript, ES6, compatible with ES5 JavaScript and used in Node.js) then building a final application occurs in another step.

This means that instead of requiring Haxe to write OpenFL projects, it is now possible (albeit for HTML5 only) to use OpenFL from TypeScript, Haxe, EcmaScript 5 or EcmaScript 6 (and newer) JavaScript flavors

There are many tools that already exist for web developers, including Webpack. In our samples, we have been using Webpack and there some fun features that have come out of the box. All of our samples use the Webpack development server for testing, which includes “hot reloading.” When you make source code changes and save your file, the project recompiles, and the test browser window reloads. This even works for SWF assets now

We also going to be able to do interactive demonstrations of OpenFL more easily, as well as many other benefits from increased testing of the codebase.

We will continue to release OpenFL for Haxelib, while also producing OpenFL releases for NPM. The Lime API is currently not available on NPM, nor are the tools, but there are other little features that are nice for quickly making OpenFL content available on the web.

For example:

var sprite = new openfl.display.Sprite ();
sprite.graphics.beginFill (0xFF0000);
sprite.graphics.drawRect (0, 0, 100, 100);

var stage = new openfl.display.Stage (550, 400);
stage.addChild (sprite);

document.body.appendChild (stage.element);

You can create use the Yeoman generator for OpenFL to create new working projects:

npm install -g yo generator-openfl

mkdir NewProject
cd NewProject
yo openfl

We also have many samples available:

openfl/openfl-samples-ts

openfl/openfl-samples

openfl/openfl-samples-es6

openfl/openfl-samples-es5

Please feel free to ask questions, and remember that we are still committed to existing platforms. The NPM approach is a new exciting way to use OpenFL in more projects

[PXshadow]

Hey so for Pirate pig demo for npm how did you setup Actuate, thanks!

[singmajesty]

I put Actuate on NPM: https://www.npmjs.com/package/actuate

I still need to give it some more love, though

[PXshadow]

is it possible to use any other haxelib? Like SVG?

[singmajesty]

It depends on your target language. Do you want to write in Haxe, or TypeScript, or JavaScript? Using Haxe, you can reference any haxelib you want in your build, but otherwise, it will need to be in JavaScript. If there’s merit, we might be able to make the SVG library available on NPM as well (for all of the above languages to use), but I wonder if there’s already a good (or better?) library on NPM that does the same, that we could build Haxe extern types for instead?

[PXshadow]

I want to write in haxe. So how do I reference a haxelib in my web pack build?

[singmajesty]

I gave it a try, and it looks like I found a solution

First, I found that Haxe 3.4.4 is not compatible with the version of Haxelib that NPM haxe installs. For this to work, you can use Haxe 3.2.1, or use a globally installed version of Haxe and Haxelib.

Using Haxe 3.2.1 (local)

1. Edit your package.json and remove the Haxe configuration value, or change to “3.2.1”
2. Add the following postinstall script:

"postinstall": "haxelib newrepo && haxelib install build.hxml --always",

3. Run npm install again

This approach creates a local “.haxelib” directory in your project, and installs libraries there (based on what you define in your “build.hxml” file)

If you need to install or update your libraries, you can use npm run postinstall

Using Haxe globally

1. Run npm uninstall --save-dev haxe

Now you can use -lib your-required-lib in your HXML, and it should use your global haxelib instead. If you prefer to have locally installed copies, you can run haxelib newrepo in the same directory as your HXML, and haxelib install to keep them local.

There is an ongoing discussion for how we can improve haxelib + NPM package integration.

[PXshadow]

isn’t it your package.json not your project.json but yeah thank you trying it out now!

[singmajesty]

Yep, that’s what I meant. Edited

Also, it would be nicer, probably, to use two scripts

"haxelib-install": "haxelib newrepo && haxelib install build.hxml --always",
"postinstall": "npm run haxelib-install"

I would also add .haxelib to your “.gitignore” file