9 issues and thoughts; show diff made to the node source code

[rahbari]

Dear @pmq20, Thank you so much for the great work. I tested your Node compiler and it's outstanding. But I have some issues and thoughts to share with you.

1- I don't know much about C++ compiling, but it seems Node Compiler compiles all the C files each time and the whole build process takes so long even on a high-end machine. Is it possible to cache intermediate C++ objects before linking to reduce upcoming build time?

2- I did some testing with fs.readFile and fs.writeFile, it seems they work on the actual filesystem and it's a good idea. But the interesting thing is stylus package which generates CSS file from STYL file and stores them in assets folder doesn't work on the file system (no assets folder is created in the directory) although an empty enclose_io_memfs folder is created (which is unnecessary and probably a bug) where executable is deployed. So my question is how can read and write be done on ram partition instead of the filesystem?

3- Be able to use a custom icon and file description for the executable output. maybe an icon file in the package root directory.

4- Have predefined node command arguments like NODE_ENV=production and besides the ability to exclude files it's possible to use compiled CSS from Stylus and compiled PUG instead of plain ones. It's also a good idea to omit devDependencies packages in the package.json file.

5- I don't know if it's possible to have the app run in the background for example as a Windows service. It's a good option.

6- It's nice to be able to exclude unnecessary node built-in modules to decrease build time, output size and complexity.

7- I use closure compiler to transpile my js file to another folder, It's nice to be able to map the compiled folder to the source one during compile time. This way source is excluded and compiled takes its place.

8- I think defining options like output, tmpdir, auto-update-url and others in package.json is better than the command line as they persist in the package. maybe this format:
{..., nodec:{output:'', icon:'', description:'', args: 'NODE_ENV=production', service: true, exclude: {files: [], modules: []}, map: [{src: './jsc', dst: './js'}], ...}, ...}

9- I read the docs but didn't find anything if Node Compiler uses the V8 Compiler feature to compile JS codes for better code protection and performance. It seems enclosejs use this feature. https://github.com/v8/v8/blob/master/src/compiler.cc

Thank you for your time

[pmq20]

Hello @rahbari , Thanks for the detailed feedback!

1- As long as the same temporary directory is used, the build time is much shorter after the 1st run. See the argument --tmpdir.

2- Currently this is not yet supported but we definitely have ways to achieve it. In addition to stylus I know some framework that does create temporary files in a location inside the project root, so it is valuable to provide a solution for these situations. One naive way is to store a big mapping in memory to serve writing and reading of those run-time-generated files. I'll implement this naive way soon and see how it goes. Do you have a sample project so I can conduct the development against? Thanks.

3- Thanks for the suggestion. I have added it to the roadmap here: https://github.com/pmq20/node-compiler/blob/master/ROADMAP.md

4- I think devDependencies is already skipped since we are executing npm --deployment when compiling.

5- yes through /subsystem=windows no cmd.exe windows are popped when executing. will do this soon.

6- Yeah we could add options to select items to deliver, like opting out zlib/openssl for system libraries, Incl and ICU, etc.

7- didn't quite get this one. Could you elaborate?

8- Yes thanks for the good idea and it is also part of roadmap of 1.x

9- we are planning to compile js to Ignition bytecode in 2.x

We are somewhat short of hand now and sorry that I have to work from the highest priority. Pull Requests are very welcome. Again thanks for all the good ideas!

[rahbari]

Dear @pmq20 thank you for the fast reply.

1,4,5- It seems readme.md doesn't fully cover these aspects of your Node Compiler.

2- What amazes me is Stylus doesn't create any CSS output files on disk (just an empty enclose_io_memfs directory) with the current compiler, and I wonder how does it work although fs.wrtieFile create files on the disk.

7- For example if we have {map: [{src: './jsc', dst: './js'}]} in package.json, node compiler should remove the js directory and rename jsc directory to js before compiling. Although it's not very important but it can be handy.

I'm really interested in contributing code to this project but I think the compiler is written in Ruby which I don't know much about. Is there any specific reason you chose Ruby over JS? I believe as this project aims JS developers, it could be a better option.

Anyway if you provide some guides on project compilation and entry points for developing new features (For example where icon file is defined and how it can be changed) in wiki pages so we can bypass try and error part.

9- I think this can be the most exciting feature of Node Compiler. I wish it could be done prior to other ones. I don't know how it works, but I'm really interested in working on this one with some help.

Thanks for the great project.

[rahbari]

Can you fork the node.js repo instead of copying its files so we can see what has been changed?

[pmq20]

@rahbari Allow me to edit the title to remind me of the 9 great issues mentioned here.

Regarding forking the node.js repo instead of copying its files, it's kind of hard to change to that route since we are already not forking it with hundreds of commits. Also the source code come from the tar-ball releases of Node.js instead of from the git repository. I recommend applying some git magic to your local git repository to check the diff, ie. just download the official tar-ball and drop it into the project which will reveal the reversed changes.

But showing the overall patch is a good idea. It is informative for the user to inspect what we have changed. I am planning to generate a page for it, as part of the document. Documents will appear on http://enclose.io I'll do it soon.

[pmq20]

Issue 2 has been implemented! Have not tried it with stylus yet but will do it soon.

pmq20/libsquash@16f038b

[ogchavez]

Not sure where else to put this but if somebody else got here like I did wanting to know about setting the icon for now while the feature gets done, is by first running nodec so the temp directory builds the nodejs folder and go into where the current icon that looks like an iron box (mine is at %APPDATA%..\Local\Temp\nodec\node-8.3.0-1.5.0\src\res) and then just replace it with your own .ico file and rerun nodec.

Btw @pmq20 , thank you for the all work done here and all the support you provided! Digging through the wiki helped a lot in figuring out how to build an app that used native modules, child_process.spawn, and learning the difference between accessing embedded internal files and local files to the executable. Wish the building process (I'll try the suggestion about using --tempdir) didn't take so long but other than that, it checks all the boxes unlike other node packagers that I tried. Thanks!