JXcore b2.30 comes with a new level of application packaging that combines all the JavaScript, HTML etc. files into an executable package. Once you package a node application, you don’t need JXcore or anything else installed on the target system.

Please note that, the packaging system is secure again. We were updating core components to handle non-V8 JavaScript engine, hence the packaging feature was mostly handling packaging of a solution instead protecting it. As a result you should update all the JX packages with the latest version in order to keep them compatible with the future versions.

Let’s say you have a basic application (i.e. ‘index.js’);

// index.js
var jxm = require('jxm');
var express = require('express');

Surely you may want to install JXM, and Express into same folder;

$ jx install jxm
$ jx install express

Let’s package the application into a .jx file

$ jx package index.js MyApp -native

And run the native application

*nix    -> $ ./MyApp
windows -> $ MyApp.exe

That’s it! You have turned the JavaScript application into a native solution without any other dependencies. Now, you can distribute your application without installing additional software on the target system.

In case you want to modify the contents / information of the package, you may simply update MyApp.jxp file, which is a project file for JX packages. Once you update modifying the package, run the method below in order to recompile the project.

$ jx compile MyApp.jxp

You can also embed jx.config with your binary in order to limit the final application’s memory, cpu or even where it should search for the packages on the target system. Create a a JSON file as shown below on the same folder and name it as “jx.config”


Now, you should add this file into the project definition. Open ‘MyApp.jxp’ and add ‘jx.config’ under ‘assets’ array. When embedded, JXcore searches for ‘jx.config’ under the assets. Remind that this feature is not available for JX packages.

Compile the package again and try it. You should receive an error that the application exceeded the allowed memory since the application should consume more than 1000kb in total. Although I don’t see a reason for someone to limit an application in such a way, there will be cases where embedding jx.config is useful. We have a plan to add automated trial – limited application compilation based on the jx.config configuration.

Please keep in mind that the name, description etc. information are entered in the JXP file since they will be defining details of the Windows binary (Right click to binary file and browse the ‘details’ tab). In case you are only interested in *nix platforms, you may indeed skip this part.

JXcore creates a binary for the platform of the local developer machine. If you want to create executables for other platforms, you have two options. The first one is to repeat these steps on each platform and create corresponding executables. This rule also applies to 32/64bit Windows binary compilation.

obastemur /

  • moussaoui91

    Great job, you are amazing!

  • http://procbits.com/pages/about/ JP Richardson

    Cool! Does this work with atom-shell or node-webkit? i.e. Can I build an app with atom-shell or node-webkit and then use this to compile a single executable?

  • Borislav Peev

    Hey, this is great. Could you make it possible to generate the native application for Windows/Linux from OSX?

  • Gerry Christiansen

    I have tried a very simple test, but it appears it does not include dependent libraries. For example, I have a very simple, single file test.js script that includes an external library from npm “oracle” aka- node-oracle. It should be noted that this library is written in c++. When I run on my build machine, it runs just fine, however when I copy up to remote node, it complains because the “node_modules” directory is missing with the library files.

    [gchristiansen@tech-master]~$ ./TestApp


    return binding.lstat(pathModule._makeLong(path));


    Error: ENOENT, no such file or directory ‘Xxxxxxxxxxx/node_modules’

    at Object.fs.lstatSync (fs.js:742:18)

    at Object.realpathSync (fs.js:1359:21)

    at tryFile (module.js:141:15)

    at tryExtensions (module.js:149:20)

    at Function.Module._findPath (module.js:184:20)

    at Function.Module._oldRes (module.js:656:25)

    at Function.Module._resolveFilename (module.js:1483:16)

    at Function.Module._load (module.js:290:23)

    at Module.require (module.js:382:17)

    at require (module.js:399:17)

  • Max Metral

    Will the paid build platform include code signing?

  • sapristi

    Nobody seems to give a damn about this comment section, but I’d really like to know if there is a way to have an external settings file, I.E. having the app to read an external file and not having that file packed with the binary.

  • Mikhael

    Looks like there are some problems with command line applications. JXCore wrap doesn’t pass params in to my application :(

    • Sergio Arboleda

      yes it is … you can use the same process.argv[1]

      • http://s2.31337.it/ S2

        process.argv[0] and process.argv[1] when run with node are ‘node’ and the script name respectively. when run from the compiled binary, argv[0] and 1 contain the first and second command line parameter.

  • Pingback: How to choose between Node.js and JXcore? - DexPage()

  • Pingback: Creating signed self-executable packages with JXcore on Windows | JXcore()

  • Prashant Biradar

    very nice project !!!