Что за предупреждения в NPM?

Я долго пользовался старым NPM (2.14) и он работал, для моих узких задач, нормально.

Сегодня поставил новый, свежий. И там при установке пакетов постоянно предупреждения:

Че за фигня? Че ему не нравится?

делали не в каталоге, где нет package.json? Может там нужно было проинициализировать конфиг вначале с помощью npm init?

Если не поможет, сделайте

npm install debug.

и покажите выхлоп.

Было бы хорошо увидеть команду, которой ставите пакеты.

делали не в каталоге, где нет package.json

Да, именно так. Package.json в том каталоге не было. А должен был быть?

То есть, скажем так, я понимаю, что _должен_, но ведь старая версия NPM не выводила этого предупреждения. А теперь оно есть. Не очень понятно, с чем именно это связано. То ли этот файл все-таки нужен, то ли по желанию.

Я не девелопер, если что.

$ npm install PackageName —save

Ну так позови билд инженера, или того кто это в репу накомитил, пусть он тебе на пальцах объяснит что должно быть и как этого добится.

Именно должен. Если до этого не требовало, то он уже был. Подругому работаь не будет. Если тебе его нужно создать, то npm init тебе в помощь.

Я вообще не работаю в IT, это для домашнего использования, в рамках хобби.

Именно должен. Если до этого не требовало, то он уже был.

Старая версия NPM (2.14) не выводила такого предупреждения. Package.json в каталоге точно так же не было.

Но вообще спасибо, я понял.

а ты вообще где это откопал. Ему минимут 3 года.

—save намекает на то, что информацию об этой зависимости нужно сохранить. Единственное место где можно сохранить эту информацию — package.json. Собственно если ты не собираешься выкладывать сорцы\сохранять информацию о зависимостях — можешь просто игнорировать, ну или попробуй убрать —save. Но лучше запусти npm init, введи хотя бы имя, а все остальное оставь по дефолту, а после этого уже устанавливай пакеты из npm.

а ты вообще где это откопал. Ему минимут 3 года.

Как поставил когда-то, так и работало. Я редко пользуюсь NPM, поэтому не заморачивался с его обновлением.

В остальном понял, спасибо.

это же нода, всё что старше полугода критично устарело.

No dice: ENOENT: no such file or directory, open ‘resources/app/package.json’ #96

Comments

soichih commented May 25, 2016

I might be misunderstanding some standard directory structure for all electron app, but I have a simple hello-world app on my local directory (from https://github.com/ungoldman/electron-hello-world) and I can run the app just fine with «electron .»

When I try to run windows-installer with following script

I get following error message.

It looks like I am supposed to put all files under resources/app directory.. But I can’t figure out where it comes from. Is it a standard to place everything under resources/app directory?

The text was updated successfully, but these errors were encountered:

MarshallOfSound commented May 25, 2016

You must first use a tool such as electron-packager to package the app into the structure that windows-installer expects.

soichih commented May 25, 2016

Ah.. I see.. How would I know!?

I’ve run electron-packager and it created whole bunch of directories for each architecture. I’ve updated the electronInstaller.createWindowInstaller() to point to -win32-x64 and saw following error message.

I am guessing windows-installer requires mono? Anyway I did following.

When I reran win.js, I got

anaisbetts commented Jun 2, 2016

mono-runtime is probably not sufficient, try just apt-get install mono

soichih commented Jun 17, 2016 •

I’ve installed mono-devel and now it seems to be doing something, but the program just sits and won’t finish.

I am running following

I have following in my appDirectory

I am running it on CentOS7 with node v4.4.4.

acepsaepudin commented Jun 23, 2016

@soichih your problem same with me 🙁

vforeman commented Jul 12, 2016

gulp winstaller (node:28462) fs: re-evaluating native module sources is not supported. If you are using the graceful-fs module, please update it to a more recent version. [14:21:51] Using gulpfile

/Development/wam/gulpfile.js [14:21:51] Starting ‘winstaller’. [14:21:51] Finished ‘winstaller’ after 2.16 ms

soichih commented Aug 3, 2016

I just tried the latest version and everything works now.

antonkarsten commented Sep 8, 2017

I had the same problems (on ubuntu). Two things solved it for me

1. install mono (http://www.mono-project.com/download/#download-lin)
2. make sure you build with electron-packager using the —asar=true switch (I had turned it of to be able to troubleshoot the result from the packager)

hutch120 commented Jan 15, 2018

If you are just getting started, consider using electron-forge instead.
https://github.com/electron-userland/electron-forge

radi-cho commented Mar 25, 2018

MarshallOfSound commented Mar 27, 2018

This issue is being closed as it is stale. This normally means that the issue has been fixed in newer versions or this issue or no longer impacting you. If this is not the case please feel free to comment with and @ mention me and we can revisit this.

qq1209974887 commented Jun 19, 2019 •

@MarshallOfSound In China, this [mono] (http://www.mono-project.com/download/#download-lin) download is unsuccessful, so the problem is difficult to solve.The problem still exists and is difficult to solve.

LeonardoRick commented Feb 10, 2021

@MarshallOfSound the problem still exists. Should we use electron-forge instead? I thought this package was so much more complete and customizable

Solving the ‘npm WARN saveError ENOENT: no such file or directory, open ‘/Users/ /package.json» error

I’m a newbie so please include links to URLs or explain terminologies so I can understand.

I’ve managed to install ‘npm’ on a Mac OS (10.13.3) via the terminal, and have installed some packages like SASS using it.

I’m now trying to install sass-mq using npm. I think I’ve managed to install it, but I’d like a second opinion on what I might have done that was incomplete, or wrong while doing it.

Initially, following the instructions on the sass-mq Github page, I was trying to use:

which gave me this error:

Looking around, I realised I’m meant to be using

..before typing my ‘install sass-mq —save’ command.

Cool, done that. Next error was this:

I think this is saying that I can’t use ‘sass-mq’ (which is the name of the package, as the name of the local package (?) I’m installing into on my local machine. Some more info here.

So I simply tried this:

and it seems to have worked OK.

My question is: Is this the right way I should have done this? How do you usually do this?

Also, I get these warnings — is it OK to ignore them?

I’m creating this question in part so others like me looking for the answer to a similar issue can find an explanation, instead of just commands they need to fix their issue. I found a few similar question-threads, but none that actually explained what was happening and why.

Thanks for reading, I really appreciate any help with this 🙂

7 Answers 7

TL;DR: The way you have done it is fine, and you needn’t worry about those warnings.

For a more in-depth idea of why npm exists and how it works, read on.

npm stands for Node Package Manager. Packages are a fundamental part of the node ecosystem — they exist to allow you to use other people’s solutions to common problems.

However, this can get very confusing, since, because this is an open source community, they are all being released at different times by different people. Also, two different packages that you use may actually be dependent on a third package that is completely unknown to you, and potentially they may even need different versions of that package.

As you can already see, this has the potential to get very messy.

npm helps you deal with these ‘dependencies’ in a way that is easier to manage and think about, however it is not essential to use npm — you can write a node app where you organise all these different files yourself. That’s going to get very confusing, very quickly, however, so there’s no real advantage in at least 99% of cases. There are also other package managers — personally I use yarn but they’re all trying to do similar things, so that choice is mainly a matter of preference and outside the scope of this discussion.

So when you start a new project, you type npm init and this tells npm to make a file in your folder called package.json that is going to help you organise these dependencies. package.json will hold the information about your own app (which is a package in its own right) and also which packages you have told npm you are going to be using as dependencies in your own project. This is why it asks you all those questions about your package name and description, so that if you ever publish it, people will know who to contact, what it does, what version it is, etc.

It is only important to give this serious thought if you actually intend to publish your package, which is less likely in the case of a website, but very likely if you’re making a library. However, as you’ve already discovered, packages are meant to have unique names, which is why you should call your package something personal to you, so you don’t end up with a naming conflict like you did when you tried to name your package the same as a package you were later going to try to install.

So let’s create our own package, and install our first dependency (which, remember, is just another package). I’m going to choose time-stamp as a dependency because it’s nice and small.

First you will make your project directory. This is just an empty new directory. Let’s call it ts . From inside the ts directory, type npm init into your terminal and answer its questions (although I usually just press return to them all,) then look inside the directory and you will see the package.json file. Open the file, and you will see all your package information. And currently that’s it.

So now back to the command line and type npm install time-stamp . When it’s finished thinking, open package.json again and you will see time-stamp referenced in the list of ‘dependencies.’ (As of npm 5 it is no longer necessary to use the —save option. npm now assumes this as default. What is the —save option for npm install?)

Back inside the directory, you will also see another file called package-lock.json and a directory called node_modules.

The node_modules directory will contain a directory called time-stamp and that holds all the code that makes time-stamp work. You probably don’t need to look in here very often, but you can, and if you look inside the time-stamp directory you will see it has got its own package.json! Open it up and have a look, and there’s all the information it needs to install itself. You’ll note that it doesn’t have any dependencies, but if it did, they would be installed in your node_modules with all of their dependencies as well. and their dependencies. and theirs. If you want to see this in action, try installing the testing framework ‘jest. Again, just npm install jest .

Hopefully the whole thing’s beginning to make a bit of sense, now.

The lock file is slightly more complicated. What it does is make sure that when you deploy your project onto a new system that you use exactly the same set of dependencies. It needs to do this because the way npm organises things can be dependent on latest release versions, etc, and it would be very annoying if you were to try to deploy your app and it didn’t work because your dependencies were behaving in a different way from your development environment!

Having said all this, basically you can ignore it at this stage! It’s an important part of npm, but you shouldn’t edit it directly unless you really know what you’re doing.

Once you have installed your dependency, you will be able to require or import it anywhere in your project, without having to worry about directing it to the correct path in your directory structure. Just require(‘time-stamp’) and it will work just fine!

Finally, and well done for getting this far, it’s worth mentioning global installation. Using the -g option — that is npm install time-stamp -g — means that the dependency will be installed in a central node_modules directory somewhere on your computer rather than in your project’s node_modules folder. However, you will still need to link it to your project (so that it ends up as a dependency in your package.json) and you would do that by typing npm link time-stamp . Personally I like all my modules to be local to my project, but again this depends on your use-cases and to an extent personal preference.

What this all means is that the combination of your package.json and the lock file is a perfect representation of all the files in your node_modules, and this means that you don’t need to have them in your git (or other repository.) You can pull your repository down to a new server, and all you have to do is type npm install and they’ll be dragged down from the internet there and then. This becomes much more important when you have a large project, because of all the files involved in your dependencies, but it’s a good habit to add ‘node_modules’ to your .gitignore from day one. But I’m starting to get off topic so maybe I should end here.

This is only intended to be a basic introduction, so I have kept it fairly simple, and I don’t want to create an in-depth tutorial, but if you need clarification on any of the points I’ve made, feel free to comment and I’ll make edits if I can!