I'm trying to compile an express web API into a binary so that my source code can be protected.
I'm trying nexe. I noticed a few pitfalls such as __dirname and __filename's behavior will be modified. I certainly can modify my own code to avoid using these two variables. However, I cannot control node_modules I referenced, or I don't want to either as there're too many of them and modifying them will cause issues in subsequent version upgrade.
Do anyone has any advice on how to handle issues like this? I'm looking for possible directions:
Compile my own code into binary, not the referenced node_modules, but still keep the reference when running the binary.
A complete different way of source code protection?
I'm using windows.
You can use pkg to compile to executable.
Related
If we want to deploy our NEST.js sever on the customer's environment, how can we hide our source code preventing from the plagiarism?
Unfortunately it is impossible to completely hide your package implementation. What you can (and should) do is using Webpack to create a bundle and minify your exported code. With that, it is pretty hard for someone to reverse engineer your code, but it is still doable.
Since Javascript is not compiled to binary, the executable of your code will always be Javascript, therefore it could be reverse engineered.
I have an emscripten/webassembly wrapped C++ class that launches and uses pthreads internally. It generally works fine when used in javascript on Chrome in its stand-alone development sandbox. However, I can't really get it to work with create-react-app and webpack (i.e. I used react-app-rewired to be able to configure webpack).
The problem seems to be from the complexity of the javascript and wasm files that a threaded emscripten build creates, and the confusion those scripts have due to the renaming of files that webpack produces. The files produced for a multi-threaded emscipten build are:
MyModule.js
MyModule.wasm
MyModule.worker.js
I can (I think) get it to work in the non-threaded mode where there is just a MyModule.js and a MyModule.wasm file through the use of the Module's locateFile method. However, the system gets very confused due to the introduction of the new MyModule.worker.js file which the MyModule.js file launches on its own within a WebWorker. And of course the MyModule.worker.js file needs to also find and get access to MyModule.wasm, and that gets lost too (i.e. can't find the right file name due to the webpack renaming).
Anyway, I've spent hours searching the web for any successful use cases like this, and trying may things, including manually editing the MyModule.js and MyModule.worker.js files, but without any luck so far.
Has anyone successfully tried something like this, or any other advice on getting a multi-threaded emscripten/wasm build to run properly with webpack (or create-react-app)? Any advice would be greatly appreciated.
NOTE: This question isn't about running a emscripten/webassembly module in a web-worker thread (although in the end I'm going to run all this in a web-worker). Its specifically about a multi-threaded emscripten build (i.e. C++ with pthreads) launching and running properly with webpack.
In Module's locateFile, you should return the correct path for MyModule.wasm and MyModule.worker.js.
Besides, In Module's mainScriptUrlOrBlob, you should assign the path for MyModule.js.
The mainScriptUrlOrBlob is used in worker for loading the wasm.
I'm just starting to learn Angular, I installed in my Ubuntu Linux:
Angular CLI: 7.1.4. and
Node: 10.14.2.
My question is, why one project is too large? I mean a simple "helloworld" is 334MB, I don't know why, Is it possible resize it? or delete any folder that is unnecessary? Or Is there something wrong with my installation? (how can I detect that?)
The bigger folder is node_modules, and when I create my projects, generates a lot of folders.
I was reading about "angular lazy loading", but I'm new.. It is not totally clear for me.
this is the folder spaces:
Please... I hope somebody can help me...
best regards
You might be using big bundles which are not needed, so you can break them up:
https://medium.com/#julienetienne/javascript-bundles-are-too-big-break-up-the-libraries-3be87d5ef487
In modern JavaScript, projects require modules that themselves require modules that require modules... resulting in node_modules directory with hundreds of dependencies. A 100Kb library might be included because someone needed one function from it. JavaScript is not compiled, so all that source tends to be rather big. This is an unfortunate, but unavoidable truth; your Angular project directories will be big, and there's nothing you can do about it. It is perfectly normal.
The good part: modern JavaScript deployment typically includes packing up those libraries with Webpack or Parcel or similar code bundlers. Most of them implement "tree shaking", which analyses the code to find only the functions that are potentially utilised starting from the entry point, and only bundle those, ignoring the rest. This means that 100Kb library whose one function is used is transformed into just that one function in the final distribution bundle.
Not all of the bundlers are equally good at it at this point. For example, Webpack cannot tree-shake the CommonJS modules, only ES6 ones.
You can remove node_modules folder when you are not going to use the app.
And, when you need work on the application, you can re-generate node_modules using the command: npm install
Those are just node-modules, they are needed for building the project, but not necessarily everything inside of them will be deployed to production. As Amadan said, there is a process of tree-shaking (filtering only used modules) and also in production you use the minified version of the same JS code (where for example whitespace is missing and variable-names are shortened), among other optimizations. A production-optimized Angular project should not be more than a 100KB for a hello-world application.
In the provided image I see packages like
selenium-webdriver
protractor
Those belong to dev-dependencies (see your package.json file) because they are used for testing. When building for production, no code from dev-dependencies should be included. The typescript package (which is nr.2 in size in your screenshot) will also not be present in production because types like string are only used for writing Typescript code, but the browser receives Javascript, which it is compiled to.
I am getting into a position where I have to use other people code for projects, for example openTLD. I want to change some of the code to give it more functionality and use it in a diffrent way. What I have found is that many people have packaged their files in such a way that you are supposed to use
cmake
and then
make
and sometimes after that
make install
I don't want to install the software on my system. What I am looking to do is get these peoples code to a point where I can add to it in Eclipse or even just using Nano and then compile it.
At what point is the code in a workable/usable state. Can I use it after doing cmake or do I need to also call make? Is my thinking correct that it would be better to edit the code after calling cmake as opposed to before? I am not going to want my finished code to be cross platform supported, it will only be on Linux. Is it easer to learn cmake and edit the code befor running cmake as opposed to not learning cmake and using the code afterwards, if that is possible?
You question is a little open ended.
Looking at the opentld project, there is a binary and a library available for use. If you are interested in using the binary in your code, you need to download the executables(Linux executables are not posted). If you are planning to use the library, you have two options. Either you use the pre-built library or build it during your build process. You would include the header files in your custom application and link with the library.
If you add more details, probably others can pitch in with new answers or refine the older ones.
This question already has answers here:
Is it possible to create desktop applications with node.js? [duplicate]
(5 answers)
Closed 7 years ago.
Is there a way to compile a node.js application?
I maybe very late but you can use "nexe" module that compile nodejs + your script in one executable: https://github.com/crcn/nexe
EDIT 2021: Nexe's latest release is from 2017 and it appears that development has otherwise slowed, so the more-widely-used alternative from Vercel should also be considered these days: pkg
Node.js runs on top of the V8 Javascript engine, which itself optimizes performance by compiling javascript code into native code... so no reason really for compiling then, is there?
https://developers.google.com/v8/design#mach_code
EncloseJS.
You get a fully functional binary without sources.
Native modules also supported. (must be placed in the same folder)
JavaScript code is transformed into native code at compile-time using V8 internal compiler. Hence, your sources are not required to execute the binary, and they are not packaged.
Perfectly optimized native code can be generated only at run-time based on the client's machine. Without that info EncloseJS can generate only "unoptimized" code. It runs about 2x slower than NodeJS.
Also, node.js runtime code is put inside the executable (along with your code) to support node API for your application at run-time.
Use cases:
Make a commercial version of your application without sources.
Make a demo/evaluation/trial version of your app without sources.
Make some kind of self-extracting archive or installer.
Make a closed source GUI application using node-thrust.
No need to install node and npm to deploy the compiled application.
No need to download hundreds of files via npm install to deploy your application. Deploy it as a single independent file.
Put your assets inside the executable to make it even more portable.
Test your app against new node version without installing it.
There was an answer here: Secure distribution of NodeJS applications. Raynos said: V8 allows you to pre-compile JavaScript.
You can use the Closure compiler to compile your javascript.
You can also use CoffeeScript to compile your coffeescript to javascript.
What do you want to achieve with compiling?
The task of compiling arbitrary non-blocking JavaScript down to say, C sounds very daunting.
There really isn't that much speed to be gained by compiling to C or ASM. If you want speed gain offload computation to a C program through a sub process.
Now this may include more than you need (and may not even work for command line applications in a non-graphical environment, I don't know), but there is nw.js.
It's Blink (i.e. Chromium/Webkit) + io.js (i.e. Node.js).
You can use node-webkit-builder to build native executable binaries for Linux, OS X and Windows.
If you want a GUI, that's a huge plus. You can build one with web technologies.
If you don't, specify "node-main" in the package.json (and probably "window": {"show": false} although maybe it works to just have a node-main and not a main)
I haven't tried to use it in exactly this way, just throwing it out there as a possibility. I can say it's certainly not an ideal solution for non-graphical Node.js applications.
javascript does not not have a compiler like for example Java/C(You can compare it more to languages like PHP for example). If you want to write compiled code you should read the section about addons and learn C. Although this is rather complex and I don't think you need to do this but instead just write javascript.