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
Related
I recently got confused and almost installed a tool via brew install when in fact it was an npm package and all I needed to do was npm install -g.
So these tools are strangely similar yet obviously different.
What's the difference in crystal clarity?
NPM exists to resolve dependencies for application code, on a per app basis, allowing an app to be self-contained and portable. This means that (in its default mode of operation) it will install the same stuff many times, uniquely, repeatedly, and separately, for every app on your system that needs the same package, inside of that apps own directory and isolated from everything else.
Homebrew is not like this. The reason is it serves the system itself, not individual apps, so is more comparable to just the npm -g part of npm.
There is one extra bit to understand about homebrew, though - some system packages have specific dependencies and could even have conflicts. This means that for the global installs that homebrew provides, it also has to solve some nesting and conflict issues. It's a kind of magic?
I should clarify that I'm not that experienced with front-end tools, so I'm sorry in advance if I'm asking something obvious and stupid.
So far I've been using bower for front-end and npm for server-side, although each of the tools mentioned has its advantages and by that I mean flat dependency management of bower (reduces load from the client) and nested dependency management of npm (helps with versioning), it has become quite cumbersome to use so many tools (webpack, browserify, etc.). I may've been using these tools the wrong way and could've used either of them with some option (not known to me) and have been only scratching the surface, I just took this answer as my rule of thumb and have been doing so ever since I've read it. It would be great if I could reduce at least these two to one.
Lately I've become curious about yarn and with all the hype around it, it seems as if it has been doing a good job and as if it will replace npm completely. As I've read the docs I've discovered the --flat option and that made me wonder if it would be possible to use it as bower replacement as well? If so, does it mean I could have either flat or nested dependency manager (by just having multiple JSON files for back- and front-end)?
I would really appreciate if someone could point me in the right direction!
It depends on your exact use case, but... probably.
Currently, the major trend seems to be towards module bundlers such as Webpack and Browserify (and hence either npm or Yarn) and away from Bower. You can read an excellent overview of the situation at NPM vs. Bower vs. Browserify vs. Gulp vs. Grunt vs. Webpack, along with some reasons why you might want Webpack instead of Bower.
At the minute, you're probably using HTTP, where it works out faster to have one JavaScript bundle file rather than lots of source files (as would occur with Bower). That's why Webpack and Browserify are so popular (among other reasons) — they should increase performance and simplify development a lot.
Side note: HTTP/2 will diminish the value of module bundling, because multiple requests will become far less costly. See What is the value of using Webpack with HTTP/2 for a more detailed description of the issues involving HTTP/2.
If you use npm or Yarn, it shouldn't really matter if the dependencies are nested—your frontend dependencies will all be bundled anyway with Webpack/Browserify, so the main cost of using nested packages is that it takes up more space and more download time.
Since npm v3 and Yarn can do flat installs, there shouldn't be any issues with that anyway. In short: you probably can do it, and many other people are doing exactly that.
In recent days, there is an upward trend in the popularity of Yarn and its mainly due to couple of things different from npm.
One, it’s 100% deterministic i.e if you run yarn from any state, any time, 1000x times, it will still work the same way all the time. npm’s installs are nondeterministic. If you run it from various states, it will install different ways.
Yarn does some better caching too. In fact, it does it so well you’ll see a significant reduction in your install times. You can see 10x reduction in install times for big application.
Yarn also locks down your dependencies by default. It’s possible to do this with an npm shrinkwrap command but if you’ve ever had to maintain one of those, it can be messy.
I use npm scripts a lot for my javascript/node projects (npm start, npm test, and npm run build and others), and I was wondering if there is something similar for elm-packages, or if we should use npm scripts instead, and if I have to do it, why do we need a package.json and a elm-package.json?
The quick answer is that (as of May 2017) there's not support for this in elm-package.json.
As for the future: Evan Czaplicki has said on elm-dev mailing list that the file format and functionality will get revamped a little bit (probably with the 0.19 release), but most probably mainly with regards to application vs. library distinction. Based on that, I don't think elm-package.json will get this functionality anytime soon.
I think most devs have some node stuff running to handle their dev environment (e.g. webpack stuff) so you will always have package.json available for such scripts anyway.
There is a question about whether elm should embed its dependencies within package.json but, while most dev instances would have package.json, anyone just trying out with elm-reactor would not. So I think the present situation is here to stay, and enables you to do what you want.
I consider to use Hexo (the static blog generator) based on npm. I wonder one thing, what if although one npm package (dependency) will not be longer available? Each package has its own author and it can cancel support or completely remove it from npm's repository at any time.
So what do I do if missing one of the npm package affect on running Hexo and consequently I'll not be able to generate my blog in the future?
Although this can happen (and happened at least once), it is not a serious problem ussually. While you will be waiting until somebody will fix the missing dependency (it take place quickly on popular packages like Hexo) you can use older working version. And if you want to be 100% sure, you can commit node_modules together with your web sources (see discussion here).
Today I found that an npm package version, Babel 6.0.15, that my application relies on had been removed from npm.
This caused compilation failure on a new pc, and I had to go manually find the closest available version for it, and all the cascading version changes it affected on related packages.
What is the best of way of dealing with npm packages, now that I know they can go missing at any time?
Do you check your node_modules folder into source control?
Is there a rule on npm about what versions (major, minor, etc) may be removed by the creator, and which are more 'long term support' and must be retained?
How do you get npm locally to inform you when 'npm update' fails on a new pc, rather than silently failing?
After thinking about this for a while I wrote a blog post summarising what I think is best practice. Reproduced below:
Summary
Specify exact versions of all npm modules, e.g. “alt”: “0.17.8”
Commit your node_modules folder into source control
Don’t use DefinitelyTyped or any other external library Typescript definition tools
Why?
Some of these principles might be controversial, so here’s my reasoning:
Specify exact versions of all npm modules
Semver (semantic versioning) says that breaking changes should occur only if the major version changes. So you should be able to say just “alt”: “0.17”
But I’ve found in practice that even patch changes (bugfixes) can break your application – because libraries that rely on these library often expect some tiny behaviour in a particular version not to change. So in order for all your particular versions of particular libraries to work, they need to rely on exact versions of other libraries.
Commit your node_modules folder into source control
I first assumed that all versions of famous npm libraries would remain there indefinitely. But I then discovered that creators often remove old versions of their software from npm – which then breaks the cascading chain of exact version number dependencies you’ve configured for your app.
Yes, committing all your npm libraries will take up space in your repository, but they’re text files after all, not .DLLs, so they’ll get compressed really small. And the alternative is one day not being able to compile your app at all on a new computer because a library has been completely removed from npm.
Don’t use DefinitelyTyped or any other external library Typescript definition tools
It’s wonderful to be given compile errors for external tools you use. But I’ve found it’s not worth the effort because:
there’s no way to match the definition file version number and npm library version number, so you get definitions that are out of sync with the library you are using
they often have bugs
the type bugs you catch at compile time are probably going to occur in your own app, not in how you call external libraries
Instead of using .d.ts files for external libraries, just say:
declare module 'lodash'
{
let x: any;
export = x;
}
Or use the –allowJS flag in Typescript 1.8 onwards.