npm init -y
I'm using above line to create node package.json file for my node project using Node Package Manager. But I want to know about -y.
What does it do?
If you will run init command with this flag you will get default package.json file. Take a look at documentation.
If the initializer is omitted (by just calling npm init), init will fall back to legacy init behavior. It will ask you a bunch of questions, and then write a package.json for you. It will attempt to make reasonable guesses based on existing fields, dependencies, and options selected. It is strictly additive, so it will keep any fields and values that were already set. You can also use -y/--yes to skip the questionnaire altogether. If you pass --scope, it will create a scoped package.
read doc here. here already mentioned all the things about npm init
npm init doc
Related
I understand the command initialises a package.json file in the CWD, I’m just curious what happens behind the scenes if the package.json file already exists.
I couldn’t find it in documentation and didn’t notice anything different when I ran it. Does the code stop once it detects a package.json file to stop overwriting what’s already there?
I'm just trying to learn more about the inner workings of this command.
Running 'npm init' will just reinitialize the package.json based on the new inputs you perform. Therefore, you're doing basically the same you did when first calling 'npm init'
See the npm docs for more information about creating a package.json file.
When you run npm init twice then it's update the package.json file as per your new init data you enter in last npm init call.
see this,
now npm init again
It will run through and overwrite the Stuff you can edit with npm init. The rest stays untouched.
First of all, huge apology for naive question and if this sounds duplicate.
I wish to install a package, for example material-ui, as an external dependency under a different path like ./node_module/my-material-ui. The problem is I don't seem to find any option to tell npm to do this other than --prefix option which actually doesn't help because it installs the package under ./node_module/my-material-ui/node_modules/material-ui. Infact, this makes sense since it prefixes the installation path. I searched around but didn't immediately find a solution.
Now as a following question, instead of individually (and locally) installing the aforementioned package using npm install ..., you wish to specify where the package has to be installed in package.json. In other words, how one can achieve the above goal by specifying that inside package.json.
Thanks in advance for your help and recommendations!
The migration guide covers this scenario.
yarn add material-ui#latest
yarn add material-ui-next#npm:material-ui#next
then
import FlatButton from 'material-ui/FlatButton'; // v0.x
import Button from 'material-ui-next/Button'; // v1.x
I see --save mentioned most of the time when installing packages. What does it mean in English? What do I lose if I don't use --save? Is it ok to just apply this option every time?
docs.npmjs.com/cli/install merely describes it as:
-S, --save: Package will appear in your dependencies
--Afternote:
I read the other question suggested as a duplicate, and I think that OP and myself were actually asking about what updating dependencies mean and not what what --save mean. It quite clear that --save means to save something, but for what purpose is the more important question. The documentation does not mention any reason. The answer given here by #nicovank helped me and I learned that it is for the purpose of duplicating the project in future, if I have not understood wrongly.
Using the save flag specifies to npm that this depedency will be saved in the package.json file, under dependencies.
You can use --save-dev to save under the devDependencies.
By using either one of those, the version saved will be for example ^1.0.0, meaning 1.0.0 or above. If you want to save the exact version you are using, use the --save-exact flag. This can be useful if you want to prevent changes in the library making your application unable to run.
Once all your dependencies are saved, you can later reinstall them all using npm install.
Is it ok to just apply this option every time?
Yes, and you should, to keep track of the dependencies of your project.
More documentation on install flags here.
I have a project, which consists of one root node package containing subpackages linked together by npm link - these subpackages depend on each other (listed in package.json dependencies) and the structure basically looks like this:
-rootpackage
--subpackageA
--subpackageB
Lets say subpackageA has dependency on subpackageB, so I link them to avoid publishing/reinstalling subpackageB in subpackageA after every change in the source of subpackageB.
The link works just fine until I run npm update in subpackageA, which causes the subpackageB to be unlinked.
Now, I see two options:
I can theoretically run the npm link operation after each npm install or npm update to ensure the links are always present. This works with postinstall in case of installation, but in case of an update the postinstall is not called. I don't know any postupdate command for npm, which is to be called after update.
Maybe there is a way to do this more cleverly, perhaps with yarn, which I am also using, in a way, that it kind of prevents unlinking or excludes the update for my subpackages, so I don't lose the links between my subpackages, but right now I am not aware of such a way.
Is there any way to make one of those options work or any other way to solve this problem ? I need to keep this and other links so we don't have to run npm link after every installation/update. I can't really find information about this issue anywhere. Btw I am using Node 6.4.0 and NPM 3.10.3.
So the solution is to use Yarn Workspaces or maybe project like Lerna.
Yarn Workspaces is a utility that expects a structure similar to what was described in the question and which maintains the linking subpackages and root automatically. It is very easy to set up (just 2 lines in root package.json and executing yarn for the first time) and after it you don't have to worry about upgrade or install at all, the links stay in place unless you delete them manually.
Lerna expands on that and provides you with additional tooling for managing multipackage projects. It can use Yarn Workspaces internally for the linking if you use yarn but it is not a requirement and works fine with npm. Just make sure to have Git because last time I checked Lerna didn't work with SVN or other VCSs.
In a Node package.json file, you can map multiple executables to the PATH environmental variable on a global NPM install (npm install -g):
"bin": {
"foo": "./bin/foo.js",
"bar": "./bin/bar.js"
},
I have a unique project that requires mapping existing PATH variables on Operating Systems that do not have it. For example, I want to add a command named grep to PATH, if and only if it is being installed on a Windows computer. If the computer is running any other OS, the NPM installation will obviously fail.
Is there any way to run logic that pre-determines what bin options are available in the installation?
Oh snap - I just had an idea!
Would this work:
Parent module has npm (programmatic version) as a dependency.
On global installation, run a post-install script as declared in the package.json of parent module.
Post-install script does a check on the system to see which commands exist. This would be more mature than "Windows or not Windows" - it would try to exec a list of commands and see which ones fail.
For every command that doesn't exist, post-install script programmatically runs npm install -g on all sub-modules (one for each command, such as grep).
This would take a while and the npm module is huge, but it seems like it would work. No?
There doesn't seem to be a way to do this directly through package.json, but it might be possible (and desirable) to do something like:
Make a separate npm module for each executable you want to register (eg my-win-grep).
In the my-win-grep module, implement the executable code you want to run, and register the PATH/executable value in this module.
In the package.json for my-win-grep, include an os field that limits it to installing on windows.
In your original module, list my-win-grep as an optionalDependency.
In this way, if someone installs your original module on Windows, it would install my-win-grep, which would register an executable to run under the grep command.
For users on other systems, the my-win-grep module would not install because of the os requirement, but the main module would continue to install because it ignores failures under optionalDependencies. So the original grep executable would remain untouched.
Updated question
This approach does sound like it should work - as you say, the npm dependency is pretty large, but it does avoid having to preform additional symlinking, and still has the benefit outlined above of having each piece of OS specific functionality in a separate module.
The only thing to watch for, possibly, in the programmatic npm docs:
You cannot set configs individually for any single npm function at
this time. Since npm is a singleton, any call to npm.config.set will
change the value for all npm commands in that process
So this might just mean that you can't specify -g on your installs, but instead would have to set it globally before the first install. This shouldn't be a problem, but you'll probably need to test it out to find out exactly.
Lastly...
You might also want to have a look at https://github.com/lastboy/package-script - even if you don't use it, it might give you some inspiration for your implementation.