Just earlier, I posted my question:
https://stackoverflow.com/questions/28336443/how-to-not-put-my-js-files-in-user-myuser-for-node-js
I have a file, hello.js, located in /Users/MyUser/Desktop/Node/
I can see that my default directory is /Users/MyUser/
Okay, so I get that I need to change my working directory. What I have been able to find so far is to use >process.chrdir('/Users/MyUser/Desktop/Node/');
Cool, that works, but now when I get out of the REPL shell, the directory resets.
The person who responded to my question said that I needed to run >node init and later npm install <name of dependency> --save
My first question: I have ran >node init and see that I can create this package.json file, what does this do exactly?
Secondly: I was told that I need to add dependancies. Could someone please explain to me what this means in Node terms? Does a dependancy simply mean a folder that I want node to include? Do I want to add this Node folder on my Desktop to be able to run my scripts?
I am currently trying to go through the learnyounode courses, however I do not want to have to save all of these test files in my /User/MyUser directory, so any advice would be greatly appreciated.
Thanks
I have ran >node init and see that I can create
this package.json file, what does this do exactly?
npm init is used to create a package.json file interactively. This will ask you a bunch of questions, and then write a package.json for you.
package.json is just a file that handle the project's dependencies and holds various metadata relevant to the project[ project description, version, license information etc]
I was told that I need to add dependencies. Could someone please
explain to me what this means in Node terms?
Lets say you're building an application that is dependent on a number of NPM modules, you can specify them in your package.json file this way:
"dependencies": {
"express": "2.3.12",
"jade": ">= 0.0.1",
"redis": "0.6.0"
}
Now doing npm install would install a package, and any packages that it depends on.
A package is:
a folder containing a program described by a package.json file
a gzipped tarball containing (1)
a url that resolves to (2)
a # that is published on the registry with (3)
a # that points to (4)
a that has a "latest" tag satisfying (5)
a that resolves to (2)
If you need to install a dependency that haven't been included in package.json, simply do npm install <packageName>. Whether or not you want to include this newly installed package in package.json is completely your take. You can also decide how this newly installed package shall appear in your package.json
npm install <packageName> [--save|--save-dev|--save-optional]:
--save: Package will appear in your dependencies.
--save-dev: Package will appear in your devDependencies.
--save-optional: Package will appear in your optionalDependencies.
Does a dependency simply mean a folder that I want node to include?
Umm, partly yes. You may consider dependencies as folders, typically stored in node_modules directory.
Do I want to add this Node folder on my Desktop to be able to run my
scripts?
No, node manages it all. npm install will automatically create node_modules directory and you can refer to those dependencies with
require() in your .js files
var express = require('express');
Node REPL simply provides a way to interactively run JavaScript and see the results. It can be used for debugging, testing, or just trying things out.
process.cwd() points to the directory from which REPL itself has been initiated. You may change it using process.chdir('/path'), but once you close the REPL session and restart, it would always re-instantiate process.cwd() to the directory from which it has been started.
If you are installing some packages/dependencies in node project1 and think those dependencies can also be useful for node project2,
install them again for project2 (to get independentnode_modules directory)
install them globally [using -g flag]. see this
reference packages in project2 as
var referencedDependency = require('/home/User/project1/node_modules/<dependency>')
Simply doing process.chdir('/home/User/project1/node_modules/') in REPL and referencing as
var referencedDependency = require('<dependency>') in your js file wont work.
>process.chdir('/Users/MyUser/Desktop/Node/'); change the working directory only for that particular REPL session.
Hope it helps!
This has nothing to do with node.js but is rather inherent in the design of Unix (which in turn influences the design of shells on other operating systems).
Processes inherit values from their parent's environment but their environments are distinct.
That terse description of how process environments work has a sometimes unexpected behavior: you cannot change your parent's environment. It was designed this way explicitly for security reasons.
What this means is, when you change the working directory in a process and quits that process your shell's working directory will not be affected. Indeed, your shell's working directory isn't affected even when the process (in this case, node REPL) is running.
This exact question is often asked by people writing shell scripts wanting to write a script that CDs into someplace. But it's also common to find this question asked by people writing other languages such as Perl, Tcl, Ruby etc. (even C).
The answer to this question is always the same regardless of language: it's not possible to CD from another program/script/process.
I'm not sure how Windows handles it so it may be possible to do it there. But it's not possible on Unixen.
Related
I've got a task that involves writing a code and I carried it out quite easily. I need to submit my solution to GitHub – according to the plan, I forked a certain repository and even cloned it to my hard drive using VS code. However, I was also told to install NPM dependencies to that newly created folder.
There are many manuals on Internet, but almost no one of them explains how to do it in a comprehensible way. As a beginner, I often struggle with all these new keywords, commands, etc and I would like to make things somewhat clearer. Do you have an idea how to get through it?
If you have already installed npm, in project directory use command
npm install
You can start with npm init in your folder. Then package.json file will be created. you can add dependencies you want to add, and run npm install.
Conflicts of a global and a local installation
I am working on the npm commandline tool and package https://github.com/ecma-make/ecmake. I ran into a strange conflict between a globally and a locally installed version of the package.
I can avoid this conflict by linking the one against the library of the other. Then there is only one instance of the library and no conflict. Now I have to think of the user, who does install the package into both places, once globally to be able to run the command without the npx prefix, once locally to have the library listed in the dev section of package.json.
How to reproduce
# prepare test fixture
mkdir ecmakeTest
cd ecmakeTest/
npm init -y
# install globally
npm install -g #ecmake/ecmake#0.3.1
npm ls -g #ecmake/ecmake
# install locally
npm install --save-dev #ecmake/ecmake#0.3.1
npm ls #ecmake/ecmake
# init ecmakeCode.js
npx ecmake --init
# run with local lib => shows the expected behaviour
npx ecmake all
# run with global lib => NoRootTaskError
ecmake all
Origin of the conflict
The stack trace guides us to the line within the global installation: /usr/local/lib/node_modules/#ecmake/ecmake/lib/runner/reader.js:21:13.
if (!(root instanceof Task)) {
throw new Reader.NoRootTaskError(this.makefile);
}
What did happen?
The object root created with the local library was checked against the class definition of the global library. They have the same code but they are different copies of the same code.
The global ecmake runner requires the local makefile ecmakeCode.js. This file in turn requires the Task definition of the local library.
const root = module.exports = require('#ecmake/ecmake').makeRoot();
root.default
.described('defaults to all')
.awaits(root.all);
[...]
We can verify that actually both libraries have been called by putting a logging instruction into both.
How do others solve this?
Gulp and Grunt export a function, that takes the actual dependency by injection. While dependency injection is generally very smart, in this case it's not that pretty. The whole file gets wrapped. I would like to avoid this wrapping function.
See: https://gulpjs.com/docs/en/getting-started/quick-start#create-a-gulpfile
See: https://gruntjs.com/getting-started
What I already considered
The runner could first check, if there is such a conflict. In case it could delegate the arguments given to global ecmake to local npx ecmake by running a child process.
Alas, this would slow down the runner. At least one subprocess is required, maybe more to check the situation.
The question
Do you have a general solution to address this challenge (apart from those I already named with their disadvantages)?
As a first part of my own answer, I do investigate, why a canonical solution is unlikely.
No canonical solution
The makefile creates a data model. The runner loads und inspects this data model and runs the instructions stored inside it. Both, the runner and the data model, need a library. There is a global npm installation and a local one. This already gives four possible combinations.
The ecmake runner provides a --base directory option modelled after the original make tool. The meaning is, "change into the named directory before doing anything". This gives a second place for a local library. We are at three times three combinations.
I will name several strategies of solutions. Combining this all, there are dozens of more or less reasonable options. This makes a canonical answer unlikely. None-the-less, the fundamental challenges of this example generally apply to many command-line tools.
Exact answers
Answers that precisely address the original questions are those strategies, that decouple the model and the runner or take care, that only one instance of the library is called.
Additional constraints
Real life doesn't answer questions that exactly. In case of ecmake the search for solutions brought up additional constraints. I want to make sure, that versions of the model and the runner match the major version, the makefile was coded against. Version conflicts at major version changes should be avoided beforehand.
Hence, the makefile should be bundled with the appropriate version in package.json. If there is only a global installation, it should try to run, but a warning of a missing local installation should be given.
I'm a little confused as to why I can't get my Gruntfile.js to run, here's the rub:
I installed grunt globally using npm. It lives in my /usr/local/bin/ directory, here it is:
Previously, I'd installed node.js using homebrew, then grunt with npm. Other issues led me to uninstall node via homebrew & reinstall node directly from the disk image node provides.
In my web project's index, there's a Gruntfile.js script that rebuilds my jekyll site everytime live-reload updates. When I run grunt, I get this message:
What I'm trying to wrap my head around:
Why isn't /usr/local/bin/grunt a valid path? Grunt exists at that location. My guess was that running grunt locally, from within my website's index, would fix things.
There's a node_modules folder there & everything was working fine before after all. I found this link, and tried running \grunt to bypass the bash alias, but that had no effect.
Any advice/suggestions are much appreciated! I feel like an imbecile using things, breaking things & not understanding why/how. Eager to finish my project, get a paycheck & finally have time to learn the ins and outs of terminal, bash & popular package managers so I don't run into these sorts of problems...
After discussion with OP, I find this is a Node.js environment issue. After install - do something - uninstall - reinstall in another way - do something, somehow, when npm install -g XXX is executed, the symbolic link is created and point to some place, but the package is installed some where else. That's why OP see /usr/local/bin/grunt but cannot run it.
I've recommended OP to clean up all Node.js stuff, make a clean environment and start right from the beginning.
Is it ok to have a node.js project with no package.json? The ones I see on the internet all come with package.json
What is the effect of having no package.json?
How is package.json created in the first place? Is it created automatically? I am wondering why I do not have package.json
Fundamentally, package.json is a meta file for your application. It lists all the configuration of your application.
What is the effect of having no package.json?
Nothing as far as you're running all your code locally and have no requirement for deployment whatsoever.
Let's setup a scene for you to understand this better.
Imagine that you wrote a brilliant application using node. Now all the chicks in your surrounding want it to play with. It is so fantastic!
Now you want to give it to them and during the development process you `npm install`ed so many things that your project grows beyond 4TB size.
There is no data storage device available to ship that huge code base.
Then the girl of your dream said I want it and I want it now. So you begin searching for app deployment process for node applications.
That is where you stumble upon a magical thing called package.json.
So what you do is you list all your npm installed modules under dependencies property. Then you delete node_modulesfolder, add package.json and commit the entire damn thing in github. Even the .zip file is of 10MB
Then she gets the code.
Types in npm install && npm start (which will install all the dependencies from the package.json` and start your application)
If you have package.json however, that is where you specify all your dependencies.
Using --save flag of npm install
Example.
npm install express --save
How is package.json created in the first place? Is it created automatically?
You can manually create a text file and save it as package.json
OR
A more sophisticated way is to use the command
npm init
I am wondering why I do not have package.json
Me too! :)
You're most probably following a tutorial that doesn't emphasize on initial configuration of the project OR the author of those tutorials presume that the reader has all the fundamentals down to begin with.
It is created automatically if you write npm init.
Then, every package you add using npm install packagename --save will be added to the dependencies list.
You need package.json so that when you want to use your project on another machine you don't have to copy all node_modules, but only your .js files you have written, assets and package.json. You can then run npm install command and it will automatically download and install all the required modules (found in the list of dependencies inside package.json).
You can also manually create or edit it, but it's easier to add --save when installing a module so you don't have to worry about package versions and stuff like that.
Also if you want to create a npm package, an open source project or stuff other people will use, it's either required or the norm to have this package.json file describing your project.
package.json is npm file, if you don't use npm you will not have this file, npm is a great tool if you want to use external libraries in your project but if you don't need it (which is very not likely unless you are doing something very simple), you don't need package.json file too.
To generate package.json file initialize npm in your project using npm init
possible reason thus it exist is you maybe you enter a wrong command like npm i -y, you must initialize the project first, just enter a command npm init -y
Welcome.
Well, if you are running it on your local machine, it's fine. now to answer your last question, package.json is not created automatically.
the npm command npm init -y creates the 'package.json' file. It basically makes sharing your code and installing your codebase easier.
I use Node.js (via browserify) for each of my web apps, all of which have some dependencies in common and others specific to themselves. Each of these apps has a package.json file that specifies which versions of which modules it needs.
Right now, I have a /node_modules directory in the parent folder of my apps for modules that they all need to reference, and then I put app-specific modules in a node_modules folder in that app's directory. This works fine in the short term, since my require() statements are able to keep looking upward in the file structure until they find the node_modules directory with the correct app in it.
Where this gets tricky is when I want to go back to an old project and run npm install to make sure it can still find all the dependencies it needs. (Who knows what funny-business has occurred since then at the parent directory level.) I was under the impression that npm install did this:
for each module listed in package.json, first check if it's present, moving up the directory the same way require does. If it's not, install it to the local node_modules directory (creating that directory if necessary).
When I run npm install inside an app folder, however, it appears to install everything locally regardless of where else it may exist upstream. Is that the correct behavior? (It's possible there's another reason, like bad version language in my package.json). If this IS the correct behavior, is there a way for me to have npm install behave like the above?
It's not a big deal to widely replicate the modules inside every app, but it feels messy and prevents me from make small improvements to the common modules and not having to update every old package.json file. Of course, this could be a good thing...
When I run npm install inside an app folder, however, it appears to install everything locally regardless of where else it may exist upstream. Is that the correct behavior? (It's possible there's another reason, like bad version language in my package.json). If this IS the correct behavior, is there a way for me to have npm install behave like the above?
Yes, that is what npm install does. In node.js code, the require algorithm has a particular sequence of places it looks, including walking up the filesystem. However, npm install doesn't do that. It just installs in place. The algorithms it uses are all constrained to just a single node_modules directory under your current directory and it won't touch anything above that (except for with -g).
It's not a big deal to widely replicate the modules inside every app, but it feels messy and prevents me from make small improvements to the common modules and not having to update every old package.json file. Of course, this could be a good thing...
Yeah basically you're doing it wrong. The regular workflow scales well to the Internet. For your use case it creates some extra tedious work, but you can also just use semantic versioning as intended and specify "mylib": "^1.0.0" in your package.json for your apps and be OK with automatically getting newer versions next time you npm install.