node_modules folder is quite large in term of size. I wonder if we can delete it after Laravel Mix compile everything? Sure, I tried it before (install jquery) and then delete node_modules folder after Laravel Mix compiled everything. My jquery code still running and there's no error at all. So is it okay?
yes, you can remove it after run:
npm run production
after run this command all necessary codes will save in app.js
and when need node_modules you can download them again with :
npm install
You should never commit your node_modules folder to git. That would take forever. Just commit package.json and package-lock.json.
However, you wouldn't want to have to re-install them everytime you build your code. I checked a large project and the total size is 310 M. What situation do you have where you can't keep that in place?
To directly answer your question, Laravel will never run code from the node_modules folder, all of the code used from there is compiled into app.js, so it is safe to delete if you had to.
Related
I am developing an application using Laravel and vueJs. During build up the application, the npm run watch command watching all relevant files for changes and recompiling app.js when it detects a change. First time, I created a repository (suppose in github/gitlab/bitbucket etc.) with a master branch and two different branches.
Now, the problem is when we're going to push to the branch or merge with master branch, it's getting so many conflicts in public/js/app.js. I guess, I know the reason. This is because of, during build the application with npm run watch, every changes recompiling the app.js. So, old public/js/app.js in the repository will get the merge conflict in new public/js/app.js. If I ignore the app.js then how the changes impact to the app when multiple developers work at the same time. In this circumstances, what should be the solution when the application is developing by two or more developers and using github,gitlab,gitbucket etc. to merge the codes. Would someone suggest me the correct way please!
Ignore compiled files in your .gitignore as there's no reason to push them to your repository unless you don't have nodejs in your server
.gitignore:
/public/js/app.js
Then run
npm install
npm run prod
In your server when you're ready to deploy
Steps to correct
rm public/js/app.js
echo "/public/js/app.js" >> .gitignore
git commit -m "ignore compiled asset"
git push
npm run watch
I usually ignore all compiled assets in public directory
/public/js/*
/public/css/*
/public/fonts
Because it's cleaner and faster to push (since the compiled assets are huge in size +1MB) to have all dependencies in node_modules and write Javascript as ES6 modules in resources/js or formerly resources/assets/js and same for SASS and CSS
You shouldn't put the compiled files in git, remove the app.js in your public directory from your git repository. Your friend just has to run npm run prod on his machine to get an updated app.js.
My Laravel project is not compiling CSS files. I did a fresh install of Laravel with laravel new project, then I ran npm install and npm run dev.
The result I get is:
DONE Compiled successfully in 7112ms
Asset Size Chunks Chunk Names
/js/app.js 1.6 MiB /js/app [emitted] /js/app
The /css/app.css is missing in the list and app.css is not emitted.
By running npm run watch (or watch-poll/hot), any changes made in app.scss is watched, and the building process is rerun. However, the result is the same - no app.css in the list of compiled files and no app.css generated.
I tried to create a new Laravel project on another computer and running npm run dev on it works without a problem. Both run on Windows 10, node version v10.16.0, npm version 6.9.0.
I tried to completely reinstall Node (to latest 10.16.0) and create a new Laravel project from scratch but with no luck.
So I finaly solved it. The problem was that I have my workspace located on D:\www and symlinked to my C:\Users\ondra\www directory. If I start npm run dev from the original location D:\www\project, everything works OK. Why it is not working from symlinked C:\Users\ondra\www\project is a mistery for me :)
another solution for this is changing the webpack.mix.js file and adding the full path for the scss source files , for example:
mix.js('resources/js/app.js', 'public/js') .sass('/home/ewertonvaz/laravelapp/resources/sass/app.scss', 'public/css');
Note that if you are using Windows you have to remove drive letter reference and the path name must be written with double slash.
Is that possible to completely remove node_modules folder from laravel app and not using it?
My app doesn't require any npm packages and I'm not using echo or pusher or any other API's that requires npm packages, then
Is it OK to remove this unnecessary folder in my app or somehow laravel
needs it to work?
If your project doesn't require node packages then you can remove it, it's not necessary to run Laravel project. But if you're using VueJS, or NodeJS then you need it.
composer update not download node packages, it only installs packages in vendor folder, node_modules is different which includes node packages.
If you want to install node packages, then use npm install command to install it again.
Hope this will helps you!
It is safe to remove the folder. The normal workflow would be to compile all CSS and JS files before deployment and copy them to the public/ directory, rendering the node_modules/ obsolete for deployment.
If anything breaks after you removed it, you can still bring it back with npm install.
I have been using npm for a personal project and just recently stumbled across yarn. Would there be any harm or "intended side effects" to switching to yarn's package manager in the same project where I had been using npm?
Although a few commenters here say its ok to mix both yarn and npm on the same project, after using yarn and npm and then yarn again, this is what yarn has to say about it:
warning package-lock.json found. Your project contains lock files generated by tools
other than Yarn. It is advised not to mix package managers in order to avoid resolution
inconsistencies caused by unsynchronized lock files. To clear this warning, remove
package-lock.json.
Since to me it is not any harm to using both them into one project.
I use npm and yarn (50/50) in dev environment.
But on ci/di i use only yarn because it is faster, and i reduce build minutes thanks yarn.
Also they both create different .lock file names.
Nobody told about the lock files.
Imagine you use yarn on dev environment, and yarn on your build/production servers. When you install a package using yarn, and your project works on your computer, you probably would want to keep it working on a production environment (your server).
That being sad, you would commit you yarn.lock file, that "saves" the exact versions of each package you have, when the project ran on your computer.
On your buid/production server you should call yarn install, but asking to keep all the same versions with --frozen-lockfile parameter. Some even say "yarn install --frozen-lockfile should be the default behavior", and I agree.
Then... another dev jump in the project you are working and install a package using npm (other than yarn). That new package will not be included in your yarn.lock file, but, a new package-json.lock file would be created, telling the exact packages versions it is using.
When that commit arrives on your build/production server, it will crash, fail, because that new package doesn't exist on yarn.lock file. Someone would need to pull that changes, call a yarn to install the dependences and update the lock file with the new package dependences, and push it again to the repo.
A quick point about using the lock file or not. If you call a 'yarn install' on your build/production server some weeks after the last install on your machine, the server would have many other new versions than your last "stable" version. It already happened to me many times.
I published recently the package-locks-checks, which help ensure you have not just one lock file but also locked each package version on your project.
There will be a point that one or both will no longer work and your project will be stuck at only using the existing lock file. Meaning, the issue probably will involve installation fails if you opt to reinstall without a lock file. And that also means failure to create a new lock file, so you are stuck with the existing one that you are trying to get rid off in the first place. We are actually encountering this issue in one of our projects. Because it is so big, no one tries to fix the issue and just rely on the existing lock file.
So, even if we say it's a rare case that it won't cause harm. Mixing npm and yarn should be avoided.
Here https://classic.yarnpkg.com/en/docs/migrating-from-npm/ we may find a confirmation that Yarn's resolution algorithm is compatible with NPM resolution algorithm.
Inside a npm project (with package.json) if you run yarn it will read your node_modules folder (using the resolution algorithm) and create a yarn.lock file with your project's locked dependency tree.
Based on that I assume that they are compatible inside the same project.
Update 30/04/2021
My original reply refers to yarn 1 (classic), although I've just created a React app with create-react-app tool and it creates the project's repository with package.json + yarn.lock by default. Again, another demonstration that it's fine (even with the warning mentioned by Dave Pile).
At the end of the day this is a matter of putting both together to work and checking yourself...
Plus you get a warning from yarn as Dave Pile said because we have to push *-lock.json files changes you have to consider using npm version >= 7 to make sure whenever you install packages by npm it will update your yarn-lock.json file too.
Because whenever you install the packages either by npm or yarn depends on what you have chosen for updating a dependency in the package.json (Using tilde ( ~ ) which gives you bug fix releases and caret ( ^ ) gives you backward-compatible new functionality) it will update you.lock file and since you have to push it might happen that you have different version of lock files.
What is the right way of removing the entire node_modules directory. Do i have to delete it right away
Ultimately you will need the modules for the application to work (if they are not development dependencies)...
If you want to erase modules you installed for development and not required in production then you can use npm prune.
Also, if you're using git you can add /node_modules to the .gitignore file, so you aren't saving libraries to your repo, and then later you can install dependencies by running npm install.
i lost count on how many times i deleted node_modules just by pressing delete button. Had no problem so far, as long as you don't forget to
npm install
everytime you delete node_modules to install dependency that is required by your app.
Best way which i found,in root of app from cmd rmdir /S node_modules and thats it.
you can use rm -rf /node_modules to remove this from project