Polyfill-service have internal vulnerable dependencies such growl, sanitize-html etc. The latest polyfill-service version v3.25.3 uses growl v1.9.2 internally which has critical security vulnerability.
Are there any alternative npm packages for the same? How to migrate the same?
Related
I would like to hard-pin my NPM dependencies. "Hard-pinning" would mean that an automated process would check my dependency list for certain packages with certain versions and if a package has been locally upgraded, an custom error message should be shown (ideally, this should be integrated in a pre-push Git hook).
The reasons for wanting this behavior could be:
external dependencies (e.g. other teams integrating with your project, requiring certain versions)
broken or unwanted behavior because of certain issues (e.g. "wait until #124 is fixed")
known non-obvious migration effort for major upgrades
upgrade incompatibilities (e.g. newest version requires, but does not enforce, a newer peer dependency).
Normal pinning does not cut it in this case: it's trivial to update pinned packages anyway, comments do not work with package.json without extra effort and sometimes the reasons are too important not to be displayed explicitly.
How can I achieve such "hard-pinning"?
I am using node-sass 4.13.1 which wraps libsass 3.5.4.
Due to security reasons we need to update libsass to 3.6.0 without downgrading the node-sass version.
How can this be achieved. Specifying the libsass version in the package.json is not feasible since libsass is not a dependency but rather a wrapped library.
Is it possible to force the use of libsass 3.6.0 after all dependencies for the repo have been installed?
Does anybody know a better solution?
I am leaning towards looking into how i can edit the scripts part of the package.json file to run a pre-install script which will force the version. Is that a good idea?
Thanks
There are forked versions of node-sass that do have 3.6.x in them, as well as a branch within the main project repo. The problem is that you will have to build it yourself in order to use them.
https://github.com/ItsLeeOwen/node-sass/tree/libsass-2b8a17a
or
https://github.com/sass/node-sass/tree/libsass-3.6.1
for example.
There is a branch available in node-sass repository which uses LibSass v3.6.3 with node-sass v4.13.1
I also faced the same issue and after doing a lot of research, the below solution worked for me:
Try installing the branch of node-sass from the github repository by using the below command (the package is already built, so you don't have to build it explicitly)
npm install https://github.com/sass/node-sass.git#v5
I have projects to maintain that use node-sass npm module.
Since node 10.x, there is a tool (called npm audit) that is run every time we do a npm install. This seems to be a good tool for preventing vulnerability issues.
My problem is that the node-sass module has vulnerabilities. I saw that the maintainers of the project do not want to fix the issues with bad reasons.
https://github.com/sass/node-sass/issues/2262
People maintaining popular module like node-sass should correct as soon as possible the vulnerability issues, but unfortunately they don't.
I am not an expert in Security, so I prefer to rely on what indicates npm and not use anymore dependencies that print messages that let you think your software is crap.
But I like so much SASS for coding CSS that I would like to give it a chance to keep it.
Any idea for removing these vulnerability messages while keeping the project safe and not reducing developer experience ?
This security issue is mainly irrelevant to node-sass since it never sees any exposure to your live code.
node-sass runs on hosts normally used for development and usually are not visible in a public network.
You normally will use node-sass to pre-compile SCSS into CSS and vulnerabilities will not impact the resulting CSS code.
These warnings are relevant if you run the node.js server as a backend which is normally not the case. (or never the case)
One option is to use dart-sass. It has no vulnerability issues.
https://sass-lang.com/dart-sass
https://github.com/webpack-contrib/sass-loader
I feel I currently have package management nicely working for me when building web applications: I keep all my server side dependencies in npm and all my client side dependencies in bower.
That said, I've been hearing talk about why it makes more sense to only use npm, especially since the release of v3. How do people keep their server side dependencies and client side dependencies from colliding when developing this way?
Can someone explain to me the difference between NPM, Bower and Composer.
They are all package managers - correct?
But when should each one be used?
Also, each one appears to have a json file that accompanies it, does this store all the packages you require so they can be installed by cmd line? Why do you need this file?
[update, four years later]
bower is deprecated, and should not be used anymore for new projects. To a large extent, it has been subsumed into node dependency management (from their website: "While Bower is maintained, we recommend using Yarn and Webpack or Parcel for front-end projects").
yarn came out of the wood as a better npm (fixing several of npm flaws), and this is really what you should use now, as it is the new de-facto standard if you are doing front-end or node development. It does consume the same package.json as npm, and is almost entirely compatible with it.
I wouldn't use composer at this point (because I wouldn't use php), although it seems to still be alive and popular
[original answer]
npm is nodejs package manager. It therefore targets nodejs environments, which usually means server-side nodejs projects or command-line projects (bower itself is a npm package). If you are going to do anything with nodejs, then you are going to use npm.
bower is a package manager that aims at (front-end) web projects. You need npm and nodejs to install bower and to execute it, though bower packages are not meant specifically for nodejs, but rather for the "browser" environment.
composer is a dependency manager that targets php projects. If you are doing something with symfony (or plain old php), this is likely the way to go
Summing it up:
doing node? you do npm
doing php? try composer
front-end javascript? try bower
And yes, the "json" files describe basic package information and dependencies. And yes, they are needed.
Now, what about the READMEs? :-)
https://github.com/bower/bower
https://www.npmjs.org/doc/cli/npm.html
https://getcomposer.org/doc/00-intro.md