Code Protection and Packaging for Node.js Projects with JXCore

by Brian Rinaldi on April 21, 2014

The modern web is always changing, and this article is more than two years old.

By Krzysztof Trzeciak

“How can I protect my JavaScript code?” This question has probably been asked millions of times and the answer is always the same. You can use obfuscation, but it will, in reality, not protect your source code. That’s why it is always recommended that you shift critical code to the server side. But in Node.js, server side code is also in JavaScript and hence is open to curious eyes unless you develop a C++ add-on, which defeats the purpose of using JavaScript in the first place. What if you are developing commercial software using Node.js? What if you are an enterprise, bound by data protection regulations wherein information cannot be left in text format?

In this article, we’ll explore how the code protection capabilities of the JXCore project can help solve these problems, along with built-in packaging features, for any Node.js 10+ project.

Code Protection

JXcore encrypts all files during the compilation of a JX package. Once compiled, only JXcore can process your application. You can consider your application completely protected, when both the library and extract properties (see the next section for more details) are set to false. Since it is not included as a library, your code cannot be easily reverse engineered using any of the reflection techniques.

It is important to note that the encryption is not obfuscation. JXcore protects your source code beyond the concept of obfuscation.

Curious developers may wonder about the outcomes when someone converts one of the interface methods to string? Interface methods are the ones exported by the interface JavaScript file. If you have ever tried to call a function’s toString() method in JavaScript, you already know that it will give you the function’s source code. JXcore helps you hide any function body from curious eyes by allowing you to choose any function to be hidden without affecting its functionality.

When you create a JX package and expose some of its methods to public, you can hide them by embedding a small comment anywhere inside its body:


We have patched the internal V8 engine to handle this part efficiently.

Now, when your package is compiled as a library, if you call:


…the body of this function is no longer available. Instead, you will see the following:


Don’t worry since the function itself can still be invoked:



One of the problems with current processes of deploying a Node.js project on the server is that they require copying a large number of files including JavaScript files, dependencies, assets, etc. A missing file or module on the server can cause the application to crash or become unstable.

JXcore’s packaging feature can solve many of these problems encountered during a regular server deployment. However, it is not only meant to simplify an application’s deployment process but to also solve other problems related to the deployment of any JavaScript server-side application with all its dependencies. JXcore packages all third-party modules together with their assets along with all of your application’s files and resources. This simplifies the deployment process.

Creating a JX package is simple and handled with a single command. The only requirement is obviously having JXcore installed.


jx package searches all sub directories for assets and source codes and creates a JXP file, which is a JX project file. For better results, the command needs to be executed under the main folder of your solution. It recursively scans the whole directory structure and puts all the supported file types into the JX file.

The JX package is not just a container for all those files. It is a completely valid application binary format for JXcore, which can be executed.


Even when executed, the JX package stays as a single file and its contents are never unpacked by default. If you are not interested in source code protection and only want JX packaging to pack your solution file then you have an option to create the package as extractable. This way, the package will be extracted on the target system whenever you call the above command line.

When the JX project file (jxp) is created, it includes all necessary information regarding to jx binary file. Turning back to extract property inside this file, when it is set to true, the package will be unpacked at its first run.

Once you have the JXP project file, you can simply update it instead of creating the project file again and again. In the case of updating a JXP file (JX project file), you simply compile it instead of creating the whole package from scratch. In order to compile a JXP file into a JX binary, use this simple command:


You can also limit a JX binary file as executable or allow it to be embedded in other solutions (i.e. require('./my_package.jx');) By default, a JX file can be embedded in any third party solution since the library option is set to true.

If you are developing a commercial application and want to prevent other developers from require()-ing or embedding your package, you just need to set library option to false and recompile the package again. JXcore will not allow the package to be called from other JavaScript files or JX packages.

Package Manager

In addition to the packaging feature, JXcore also offers another related tool: the Package Manager. It allows you to install npm modules in an easy and convenient way. It does not require the npm tool itself to be installed. Also, several popular Node modules are available as JX packages. The process to install a module is extremely simple. The command below will download the express.jx package:


The express.jx package is in fact the Express module packed into JX package and kept in JXcore’s repository. The above command takes it from there and writes it to the current folder.

You can also install it globally. But then it will not be installed as jx package anymore. Instead, it will be installed like any regular npm module:


What’s Next

Code protection and packaging are just two of the key features in JXcore, but there are other features like multi-threading and messaging API already included in our latest release.

We are also working on some very exciting features, one of which is to replace the V8 engine with LLVM. This feature alone would enable JavaScript programmers to develop native apps. This is going to take some time to complete but we have many other features coming soon, so stay tuned.

JXcore is free to use and redistribute and available from here.


  1. Jordan Alexander says:

    Um… server sided JavaScript is not available to the public eye? This article is completely wrong.

    1. remotesynth says:

      He was talking about distributing the modules . Sine it isn’t compiled, the source is open to anyone.

      1. Adrian says:

        But why would you want to distribute it if you didn’t want somebody to look at the code?

      2. to distribute a node.js application in closed source format. IP protection.

  2. visualjeff says:

    We have just been teleported back to the year 1996. ;-}

    Anyway, its good to know such an option does exist.

  3. Tester says:

    Well, sometimes you want to distribute server side modules and in the same time you don’t want the users of this modules to see/copy/use your code.

  4. pragmatic says:

    Problems with packaging bower dependecies.

    I’d really like to make use of jxcore and its packaging feature, however there were errors while I tried to run a packaged app. It was generated by yo with angular, bootstrap, using bower and gulp. I made a package (tried different levels, configs, etc.). When deployed, jxcore couldn’t run it unless I deployed all unpacked bower dependecies.

    I can’t find any info about it on the net. Am I doing something wrong or jxcore does not support packaging bower and other resources yet (that would be weird)?
    Maybe you could provide an example (github code) of packaging such heavily dependent app?

  5. weasel says:

    this have been already cracked. see:

  6. Jebus says:

    In a first instance this article could be unnecessary or wrong, but when your are in front to the problem of distribution of your modules, protection is required. No just to protect your code from other developers and lost your work but rather to protect third party information (eg. APIs under NDA contract). I mean, javascript are moving really fast from browsers, back-end and now with native applications such as electron or NWJS. I think that this article is appreciated when is read it for someone that has had these probles to resolve.


Leave a Reply

Your email address will not be published. Required fields are marked *

© 2016 Modern Web & our authors. All rights reserved.