node.js zip utilities that works with node-webkit? - zip

Has anyone been able to successfully create a zip file that can be read by node-webkit using any of the node.js zip utility?
I have tried node-zip, admzip, node-archiever, etc. but havent' had much luck. For one reason or another, none of the files can be read by node-webkit (and sometimes by, say, winzip as well)

Try to package your app with the tools provided by the Yeoman Generator: https://www.npmjs.org/package/generator-node-webkit
$ npm install -g yo
$ npm install -g generator-node-webkit
$ yo node-webkit
Then, put your code inside the app folder and run one of these:
grunt dist-mac
grunt dist-win
grunt dist-linux
This will package your app and leave the executable on the dist folder.

Related

NodeJS - npm install practice

Created new folder and did npm install serve in it.
It created package-lock.json and node_modules/ folder.
When I run in the same folder serve it shows error:
command not found: serve
What is the way to install?
I am using: npm#6.5.0
My dev environment is MACOS
I read a great many pages on this topic and nothing worked until I tried the following
./node_modules/.bin/serve -s build
Also if you are using VS CODE you may want to bring up the terminal window outside of VS CODE - this seems to have snared a lot of people.
First of all, you should start your project running
npm init
This will create the package.json file.
Then, you can install the serve package globally.
npm install -g serve
And now you can run serve.
The serve binary was not found because the operating system cannot locate it in the PATH environment variable.
When you do the npm install serve command. The serve module is only installed into the node_modules directory found under the the project folder. Unless you explicitly include the absolute path of this node_module directory as part of your PATH env var, the OS won't know where to find serve.
Like others say, the typical practise would be to install the module using the -g flag. G means global.
When -g is used, npm will put the binary in its node directory somewhere and this this directory would have been included as part of your PATH when you install node, thus making the any new binary discoverable.
If the node.js module has a "command" and you want to run it without installing the module globally(npm install -g serve). You can run it like ./node-modules/.bin/command from the root folder of the project.
Now, what is generally used is npx, so that you can from within a project easily run any of the binaries within its local node_modules or your system's global node_modules/ and any other commands on the $PATH.
For example, here we install webpack as a local dependency. You can image doing this in a folder after running npm init. Then we run webpack without having to worry about referencing the bin file:
$ npm i -D webpack
$ npx webpack

Ember CLI ember new and ember init files not showing but buildable

I'm using ember v1.13.15, node: 5.4.1, npm 2.14.10 and os linux x64 (ubuntu). I'm actually trying to get ember-cli into my rails app. When executing ember new frontend I get the output that a bunch of files were created. These files don't show up in nautilus, terminal via ls nor can I cd into the directory. I manually typed mkdir frontend && cd frontend then ember init with the same results. If I run ember init again it recognizes the files are there because it asks me if I want to overwrite some files.
Running ember build produces a successful build, but where are the files?
Updated with terminal
uhoh#eblinux:~/Documents/apps/mvp$ cd frontendconsumer/
uhoh#eblinux:~/Documents/apps/mvp/frontendconsumer$ ls
uhoh#eblinux:~/Documents/apps/mvp/frontendconsumer$ ember init
version: 1.13.15
Could not find watchman, falling back to NodeWatcher for file system events.
Visit http://www.ember-cli.com/user-guide/#watchman for more info.
installing app
identical .bowerrc
identical .editorconfig
identical .ember-cli
identical .jshintrc
identical .travis.yml
identical .watchmanconfig
identical README.md
identical app/app.js
identical app/index.html
identical app/router.js
identical app/templates/application.hbs
identical bower.json
identical config/environment.js
identical ember-cli-build.js
identical .gitignore
identical package.json
identical public/crossdomain.xml
identical public/robots.txt
identical testem.json
identical tests/.jshintrc
identical tests/helpers/destroy-app.js
identical tests/helpers/module-for-acceptance.js
identical tests/helpers/resolver.js
identical tests/helpers/start-app.js
identical tests/index.html
identical tests/test-helper.js
Installed packages for tooling via npm.
Installed browser packages via Bower.
uhoh#eblinux:~/Documents/apps/mvp/frontendconsumer$ ls
uhoh#eblinux:~/Documents/apps/mvp/frontendconsumer$ ls -a
. ..
Update v2
uhoh#eblinux:~/Documents/apps/mvp/frontendconsumer$ locate test-helper.js --all
/home/uhoh/Documents/apps/integration/node_modules/jshint/node_modules/htmlparser2/test/test-helper.js
/home/uhoh/Documents/apps/newapp/node_modules/jshint/node_modules/htmlparser2/test/test-helper.js
/home/uhoh/Documents/apps/vd-integrations/test/test-helper.js
/home/uhoh/Downloads/ace1.3.1/mustache/js/node_modules/htmlparser2/tests/test-helper.js
/home/uhoh/Downloads/ace1_3.0/mustache/js/node_modules/htmlparser2/tests/test-helper.js
/home/uhoh/Downloads/ace3/mustache/js/node_modules/htmlparser2/tests/test-helper.js
/home/uhoh/consumer_frontend/node_modules/ember-cli/blueprints/app/files/tests/test-helper.js
/home/uhoh/consumer_frontend/node_modules/ember-cli-babel/tests/test-helper.js
/home/uhoh/consumer_frontend/node_modules/ember-cli-content-security-policy/tests/test-helper.js
/home/uhoh/consumer_frontend/node_modules/ember-cli-qunit/node_modules/broccoli-jshint/node_modules/jshint/node_modules/htmlparser2/test/test-helper.js
I am unable to comment, so instead I will offer you two main options:
Uninstall all ember related packages and push node to 5.6.0 and npm to 3.6.0 (the version that I using.)
npm uninstall -g ember-cli
sudo npm cache clean -f
sudo npm install -g n
sudo n stable
Install Ember and the needed packages, confirm version of node and npm and try to create the project.
Probe the files on the frontendconsumer folder:
Typesyncand see if something shows up on Nautilus.
Use locate test-helper.js -c or locate any other file that was supposed to be there. If the result is 0 then give the other locate params a try.
Type baobab and see if something shows up on the folder.
If nothing yet, then try find -type l to see if there are any symbolic links.
Run a checkdisk on your hard drive.
If none of those options helped, then something really weird is going when scaffolding the new application... If there is no other issues on your system, try to create a rails app through RVM to see if the scaffold of a new app works out. If it does, then chances are that something within npm, node or the ember packages are bad. Otherwise, it may be your system.

File Structure MEAN .IO After mean init MyApp

After setting up node bower grunt and mean I run mean init myApp which prepares me a new project. At that point I go into the app and run
npm install
After my project is installed I can run the app with no problems and everything looks great. But the amount of files and folders is a bit overwhelming. I have searched for a tutorial explaining the file paths but can't find one that matches my current build after following those commands right off of the mean.io website.
$ sudo npm install -g mean-cli
$ mean init yourNewApp
Someone please provide me with some documentation to read through to understand what's being installed following those commands and how to weed through it to understand how to start working with mean.io
The file structure is int he picture below.
Config is for env-based and global configuration.
Gulp is the gulp scripts for running \ updating \ minifying
Logs contain the application's logs
node_modules contain npm dependencies (standard)
Packages contain core and custom packages
Tests contain the test configuration files
Tools contain general scripts like npm's postinstall actions (for example, propagating bower install to all packages)
The documentation describes the folder structure for packages (which is almost the only interesting folder in terms of functionality development):
Also, John Webb has a couple of useful mean.io video tutorials which might help you find your way around mean.io:
Getting Started
Customization

How to put local node package on path?

Newbie question. I have chosen not to install express with -g option. I did not use npm -g which would put it on the path globally. Instead it is installed in my local mac user directory. What I am not clear on is exactly what or how you put a package like express on the path so it can be invoked etc? What exactly needs to be on the path (node_modules?) so these packages are available just like a -g installation? I could have used home-brew I suppose but anyway, I now have all node packages and everything local. Another situation is that I am not able to run any of the nodejs tutorials. Although there might be smarter ways to do this, I wonder if sudo is really such a good way to install a development package ....
Now for example, I want to run the tutorial javascripting which is a nodejs tutorial. How do I do this. If I just type:
Mac1$ javascripting
it finds nothing.
Same for
Mac1$ express
UPDATE: THIS WAS ANSWERED IN THE COMMENTS
The commands exist in a hidden directory after a regular
install npm install express
in my case this the command goes here: /users/MAC1/node_modules/.bin
It is this path that needs to be placed on the $PATH as described in the first comment.
Thanks guys.
npm installes executable to two places. By default running a npm install in a project will install any binaries in ./node_modules/.bin. When you use the -g flag (npm install -g package-name) it will install into a global path. You can find out the global path by running npm bin -g. Add that to your path and globally installed executables will be accessible.
You can also add ./node_modules/.bin to your path to allow easy access to executables added by packages in your project folder. I admit to using this on a trusted local machine. However, this is very dangerous and not a recommended way to expose the executables in the node_modules directory.
Best alternative is to add the executable to the scripts section of the package.json file and then use npm run-script <command> which will auto prepend the ./node_modules/.bin when executing.
package.json
{
"scripts": {
"foo": "foo --arguments"
}
}
Example
$ npm install foo
$ ls ./node_modules/.bin
foo
$ npm run-script foo
# Executes:
./node_modules/.bin/foo --arguments

Managing node packages in a optimized way

I am newbie in Node.js.
Whenever I want to install a package, I do it like
"npm install -g package-name"
What I have seen inside my node applications there is a dir "node_modules" been created and all the installed modules are there.
Then I want to use "grunt" for automating my tests for frontend javascirpt unit tests.
And I ran the command for installing "npm install -g grunt" but when I go inside my test directory and run grunt I get "Fatal error: Unable to find local grunt." But if I install it inside the "test" directory it works fine.
My project structure like below:
-backend
-tests
-model
-node_modules
-package.json
-others
-frontend
-tests
-js
-package.json
-node_modules
-others
How I can manage node packages from a single pacakge.json and run the tests separately in frontend and backend? What are the optimized way of doing this stuff?
Thanks in advance.
The -g flag in npm will install the module globally -- this is how things like grunt work as a CLI tool, but for your dependencies, you probably just want them to be installed in your node_modules folder, defined in your package.json.
Are you browserifying your front-end modules? You most likely do not want both your front and back end to have the same set of dependencies, best to keep them separate package.json manifests. Are your frontend modules just grunt tasks? Running grunt in either frontend or backend directories will call the gruntfile only there.
Keep these two directories separate -- will save a lot of headache in the future.

Resources