I am wondering if it is an acceptable practice NOT to use .gitignore entirely and commit everything there is, at least for small to medium projects.
Laravel, as any framework I can imagine, has a lot of dependencies so they are set up to be ignored by git. This is what my default
Two part answer.
You mentioned that your vendor/node_modules folders exploded in size. Even though you don't have them in version control - if you are using composer and npm correctly (by using the --save directive for npm), all modules should be listed in composer.json and package.json respectively. Meaning even if the installed libraries (in vendor + node_modules) weren't in version control, the package.json and composer.json should be - meaning you should be able to go back through time, and install the packages at that point in time using your composer/package jsons.
Second part to this answer is should you include vendor/node_modules in version control? This is a fair question, and one often asked. I think ultimately it depends on your intention to deploy.
Do you have essentially unlimited space on your origin (github, bitbucket, etc) and you want your deployment to be a simple super
git push to your production version? You can probably just commit everything, including vendor libraries. That way you have complete control of what is going up to your server.
Realistically, you might need to
php artisan migrate when you push, so in turn, you might start to consider git hooks, and the process starts to become a bit more complex (but arguably better/scalable/robust). With those hooks in place, you could start to look at running composer install + npm install against the package.json and composer.json files (without the entire vendor libraries in git). If you go this avenue, you want to make sure your composer/package jsons are nice and locked down - no '3.x.x' version numbers - you want locked down versions that you know work and have been tested.