express --ejs --css sass --git
above command install node-sass-middleware npm automatically.
since I found that a lot of people use node-sass npm, I wonder what the differences are between those two.
I have searched some, and many articles seems to recommmend using node-sass npm.
so why then express generator supports node-sass-middleware npm?
any advice might be helpful.
NodeSassMiddleware basically includes the node-sass package automatically when you will install it as package, so use node-sass-middleware package.
Related
So, I had used sass before using npm install node-sass for my reactjs project. I'm now working on a new project and wanted to use sass again. With the same syntax npm install node-sass to get it installed, I continued to get
./src/components/Main.scss (./node_modules/css-loader??ref--6-oneOf-5-1!./node_modules/postcss-loader/src??postcss!./node_modules/react-scripts/node_modules/sass-loader/lib/loader.js??ref--6-oneOf-5-3!./src/components/Main.scss)
Error: Node Sass version 8.0.0 is incompatible with ^4.0.0.
Or
to import sass files, you first need to install node-sass. run `npm install node-sass` or `yarn add node-sass` inside your workspace
...
...
I followed the instructions to have sass installed from the links npmjs
sass-lang
using these syntaxes
brew install sass/sass/sass
npm install -g sass
but I'm still encountering either errors I mentioned earlier.
I tried deleting the node-module folder, package-lock.json and reinstalled node-modules. That still did not fix the error. Also, I followed how others got around fixing Node Sass version 5.0.0||6.0.0|| 7.0.0 incompatibility issue but that did not fix mine.
I'm seeking help now.
Don't use node-sass anymore
You can easily fix it by the following.
npm uninstall node-sass
npm install sass
This is because node-sass is now deprecated. You will have to install its new version which is sass. Sinc it works all the same and better, this will easily fix the issue without making any additional changes.
And all Works well !
But if you still prefer to use node-sass
You can use the following table to install the appropriate version node-sass for your installed Node.js version which you can check by the command node --version.
npm install node-sass#(your version)
update sass-loader, or remove and install again.
Try this: In your packege.json file, delete "node-sass": "^4.12.0" and replace it with "sass": "". This did it for me.
You can follow these two steps:
Uninstall your node-sass:
npm uninstall node-sass
Install old version node-sass:
npm install --save-dev --unsafe-perm node-sass#4.14.1
It's okay now
The answer for me was to update react-scripts to 4.0.3. I couldn't do the latest version of react-scripts because it still requires a bunch of hacks to make packages work that had polyfilled modules automatically loaded before.
I'm referring to the standalone installation from GitHub and adding it to PATH vs. npm install -g sass. Both are Dart Sass, but the npm version is compiled to pure JavaScript.
The official installation instruction says that Sass installed through npm is slower than a standalone installation (from GitHub and adding it to your PATH). Is this referring to performance when compiling locally? Would it have an impact on end-user performance?
What about the productivity? Is npm faster and easier to install, as well as easier to add to a project? Can I install it globally while also using the --save flag to add it as a dependency to the project?
Are there any other implications of choosing one over another?
I have an electron/React app running. So after I install all packages I have to execute electron-rebuild so there are no version issues.
I install one package in the preinstall script: npm install better-sqlite3 --build-from-source --sqlite3=my sqlite amalgamation folder
Now the problem is that electron-rebuild/npm rebuild just installs better-sqlite3 and not better-sqlite3 with my customized amalgamation.
This makes it unusable for me because I need my customized version of sqlite.
Does anyone know how to solve this, how to make electron-rebuild/npm rebuild install that package with the extra parameters?
I created a library to fix this issue/get around it: https://www.npmjs.com/package/better-sqlite3-sqleet.
So the problem is solved for me, but it would be nice to still have an answer on the original question.
I have a project with a package.json file and an install bash script that, among other steps, runs npm install.
I'm thinking of updating the script so that it runs yarn install if yarn is available (to take advantage of yarn's caching, lockfile, etc), and falls back to npm install otherwise. As far as I can tell, all the packages seem to install and work ok either way.
Are yarn and npm interchangeable enough for this to be a viable approach, though? Or are there potential issues that this could lead to? Are we meant to just pick one, or is yarn interchangeable with npm in practice?
(nb. I've read this closely related question, but I'm asking this as a separate question because it's about explicitly supporting both yarn and npm install processes in a project)
Yarn and npm (version >=3.0.0) should be relatively compatible, especially moving from npm to Yarn, because compatibility is one of the stated goals of Yarn. As stated in Migrating from npm:
Yarn can consume the same package.json format as npm, and can install any package from the npm registry.
So, in theory, any package.json that is valid for npm should also work equally well for Yarn. Note that I say that npm v2 is probably less compatible - this is because npm migrated from a nested node_modules structure to a flat layout (which is what Yarn uses). That said, Yarn and npm v3 should produce very similar layouts, because, as stated in the issue I linked:
To a first approximation we should try to be very compatible with the node_modules layout for people who need that compatibility, because it'll be the most likely way to avoid long-tail compatibility problems.
However, you will not be able to take advantage of the Yarn.lock generated by Yarn, because (as the name suggests) it's only supported by Yarn, and npm shrinkwrap is not compatible.
Also, as noted by #RyanZim, older versions of Yarn don't support pre- and post-install hooks, but versions later than v0.16.1 do. If you rely on these hooks, you will need to specify to users that versions greater than v0.16.1 are required.
In summary, as long as you encounter no bugs and only use features that are shared by both package managers, you should have no issues whatsoever.
I've started using npm for JavaScript package management recently. Although I do have a fair understanding of package management in different environments (let’s say using apt, rvm/gem, and pythonbrew/virtualenv/pip), I don't quite understand how npm fully fits in.
I would like to know more on how the "-g" flag works and why should I use it.
As in most blogs and wiki, they refer to using "-g" when installing without explaining why, and I understand that these packages are installed globally.
But why should I always install these packages globally?
What does it mean to install these packages without the "-g" flag?
What do I do to installed packages locally, let’s say sandboxed for different projects?
How can I then, make a list of npm packages used in a project and bundle it in the project if I needed it to check it in with version control (if possible at all)?
-g is the global install flag, as explained in this answer. It's covered in detail in this node blog post.
The rules of thumb:
Install globally if the package provides command-line tools
Install locally if you're using the package as part of your application
Install globally and locally if both use-cases apply
While the accepted answer is correct, be aware that there is also npx which allows to conveniently run local tools.
For more information, see Introducing npx: an npm package runner