If I write a package I am certain requires Node 4 or higher, I don't want it to be installable with older versions.
I know about the package.json engines field, but that's just advisory (only causes a warning). And enginesStrict has been deprecated.
So what can I do?
One idea is to have a preinstall script that checks the Node version and errors if it's not high enough, preventing installation from continuing. Are there any problems with doing that? And is there a better way?
If you want a good experience, make your CLI entrypoint standard ES5 and CommonJS, detect the node version (process.version), and print a detailed and helpful message then exit non-zero. Keep in mind your module may get installed with some node version then the user futzes with nvm or their PATH or whatever and then runs your code under a different version. Thus I think failing nicely at run time is the most important thing. You can also choose to fail at install time if you like.
Related
For instance, say I have "foo: ^1.0.0" listed in my package.json and that project's released versions are [1.0.0, 1.1.0, 1.2.0, 2.0.0]. I want to find out what ^1.0.0 resolves to without installing or looking it up manually. Does a tool for this exist? I would expect it to be something like npm resolve foo#^1.0.0
Yes there is!
If you're using npm use view
npm view foo#^1.0.0
Otherwise you could use yarn with info
yarn info foo#^1.0.0
And in case you want even better statistics check out bundlephobia. It gives size estimations for the given version as well as the others and also an analysis of the exports.
I'm have a small npm package which I'm writing in node 9 and using all the latest and greatest features like async/await. I'm also using babel which allows me to use ES6 module imports and exports
Babel also allows me to transpile the package to a target node version. I'm using the node release schedule to define which version of node the package will support and with the the target for the babel compilation. Currently node 4.x is still in maintenance lts stage, so I'm targeting it. Unfortunately this means almost every new feature in JavaScript I'm using gets transpiled.
What I'd like to do is to transpile the package to different targets (4.x, 6.x, 7.x, 8.x, and 9.x currently apply) and have npm choose the appropriate build of the package at install time based on the user's node version. If I'm not mistaken, I've seen apt-get do this with different versions of Ubuntu.
Is this possible with npm?
I'll bump an old thread here. A good option is to use two separate directories and choose the transpiled version depending on process.version.
I'll be trying to do this in scramjet and will be updating the thread along the way. My plan is to use an index.js file like this:
const ver = process.version.slice(1).split('.');
module.exports = require(+ver[0] > 8 && +ver[1] > 3 ? 'lib/index' : 'lib-6/index')
This should do for now, but since I also have some v10+ targeted code (especially DataStream.from(async function*() { ... }) which has some ifs in it I may want to extend it later and use a table.
What's important here is that the code above runs once (unless you clear require cache) and mostly in compile time so it has minimal influence over your module.
My current npm version is 3.7.3 . Previously, only the required packages were getting installed in my node modules. But right now they have all flattened and have 100 + folders visible when I look into node modules. I prefer the older way where you could go into individual folders and see their dependencies.
here is a similar thread:
Why does npm install many packages into "/node_modules" instead of only one?
I tried running npm uninstall without much success.
Basically, you are out of luck... NPM does not provide any configuration options regarding this. It will nest dependencies if it must in order to resolve version conflicts, but only in this case. Your only option is to downgrade NPM (not recommended). However, if you just need to see the dependencies nested for informational reasons, you can use npm ls. It will draw you a graph.
See this relevant NPM issue for more discussion: https://github.com/npm/npm/issues/9809
Now that node js' LTS doesn't include an NPMv2 I found myself stuck with this issue again.
For those of you also caught out, the link that #KevinBurdett mentioned, also has some answers.
You can force downgrade npm using npm itself (using sudo or equivalent for this). From https://github.com/npm/npm/issues/9809#issuecomment-179702479:
as root I simply do npm install -g 'npm#<3' on my system every time I
a new version of Node comes out; your mileage might vary, but it's
fairly trivial to "downgrade" :-)
Another alternative is to use the Node Version Manager (NVM): https://github.com/creationix/nvm. Your mileage may vary depending upon personal config/preferences/platform.
That said, npm 3 and the issue of flat dependency trees will be with us from hereafter... It's probably high time to start accepting that change.
My personal grudge with this is that it makes the node_modules folder incredibly difficult to work with in an IDE, especially when you need to look at the implementation of your immediate dependent modules, without first wading through 100's of sub-sub modules that are irrelevant to me. It seems that I'm not alone in this matter when you read the comments in the issue. It only leads me to question the viability of npm itself when such changes are made without a proper migration from old to new systems. For me, npm2 will always be king.
I'm new to Electron, and I really love it so far, but I'm unable to package any of mine apps, at first I thought that it's maybe something related to my code, then I download "https://github.com/atom/electron-quick-start" run npm install and then I run "electron-packager . FooBar --platform=darwin --arch=x64 --version=0.28.2" it build the app but when I try to open it I get
so I didn't touch any code from the example, just wanted to build it and I got an error, what am I doing wrong? Thanks!
The versions of electron are moving very very fast.
And some times, they don't respect the "old" ways to do things (for example, declaring the app).
I advise you to not use the 0.28.2 version of electron but the most recent one.
It is very likely that the version of electron-prebuilt you are using to develop is much much much more recent than the 0.28.2 version. So, you are developing with something much newer, and then you are building with 0.28.2. This would cause the exact error that you are seeing, as older versions may not have had the electron module, which your code explicitly is importing. So... that is my suggestion. Change the version in your electron-packager command from 0.28.2 to something like 0.36.0. See if that works. Or better yet, use the same version as electron-prebuilt in your package.json.
This could be a combination of factors.
First, as others stated, the version of electron that you have might be newer than the one referenced in your build command. Locate the 'electron_prebuilt' folder inside your 'node_modules' folder, and examine the package.json file and make sure the version # is the same as what you are declaring in your build command.
If they are the same, then the issue might be that you have another version of electron on your computer that node is trying to use. If you installed electron via the -g option (global), check your home folder to see if there is another different version of electron. If you find one, either delete it or rename the 'electron_prebuilt' folder you find to something else. Try your build command again, and it should work now that you've eliminated the other versions of electron_prebuilt on your computer that node was referencing.
What worked for me was to move the "electron" module from "dev-dependencies" to "dependencies" in package.json. Try this and see if it works.
Full error/warning log: http://pastebin.com/xNjC4FDr
I had problem as well when I tried to install MongoDB, I have made SO question of it but, that was only warnings, so I could ignore it. But this time it's not only warnings, but also red error.
What do I have to do? Is my Nodejs messed up because I've installed Visual Studio Tools for NodeJS in the past? Or is this normal behavior? What can I do about this, I prefer not to see errors/warnings when I install something on NPM.
The problem is that hiredis does not support Windows currently. The link to the Windows-compatible fork in the hiredis readme seems to be outdated (last commit in 8/2013 as of this writing), so you may be out of luck.
However hiredis is not required by the redis module, it's an optional dependency that just makes parsing the redis protocol faster than the pure JavaScript parser that is bundled with redis. You may see a similar thing with other modules that have optional dependencies like this. Typically if you see the module tree outline at the end of the console output, that means the module installation was successful.