Which directories / files can i remove safely from the laravel package?

They're all used by laravel. Laravel doesn't include things that "aren't used".

I've deleted a lot of README.md, composer.json, and so on, without any problems. most in "vendor" directory.. Now my upload is a lil bit smaller...

And i think i don't need all the unit test cases, for example?

That's up to you. Personally I run unit tests so wouldn't delete it...

i removed all

• .gitattributes
• .gitignore
• artisan
• composer.json
• composer.lock
• package.json
• readme.md
• readme.txt
• ...?

(When i remember right..)

but these files are really small in size - it looks like you have a shared hosting and are doing uploads..

you shouldnt be deleting any files/folders.. why do you feel you need to do that? if you remove composer, how are you going to update your packages? add more when you need them? if you remove artisan, how will you run commands/queues/workers..

Thx.

" it looks like you have a shared hosting and are doing uploads.."

Exactly..

There is also an option in some ftp clients to exclude files! ;)

Better keep that files on dev or test environments, and write a build script e.g. with ant or maven... i would not deploy unnecessary things on productive systems.

You can remove everything except for 1 file. Just delete everything except for public/index.php

Then edit that file, just delete everything - and you can start coding!

This kind of gets away from all of the wonderful features of Laravel, but it will be super streamlined - to start with.

Do you realize how much easier updating would be with composer.

I usually update app if needed first from a stable release, then just a composer update is all that's needed.

Just delete everything except for public/index.php

Funny

Edit: Are you the one who also came from java, as did I.

I guarantee using composer (git also needed) and setting up laravel. And using one of the wamps, I use bitnami some use xampp, is childs play compared the the old manually setting up a tomcat server.

I'd say compared to that setting up a laravel development environment is like 2nd grade stuff compared to the old days manually setting up everything.

"Do you realize how much easier updating would be with composer."

One day i will try it, when i have the time.

"Edit: Are you the one who also came from java, as did I."

Yes.

"I guarantee using composer (git also needed) and setting up laravel. And using one of the wamps, I use bitnami some use xampp, is childs play compared the the old manually setting up a tomcat server."

I think the current eclipse ("pdt") version has composer included? (I'm able to create a "composer project" or someting like that there)

"And using one of the wamps, I use bitnami some use xampp, is childs play compared the the old manually setting up a tomcat server."

Yes, Laravel works well with LAMP & WAMP, i tested it...

Wait, you just said you removed .gitignore, artisan, composer.json and composer.lock - wtf? Additionally those files are tiny in size. Hope I never have to work on one of your projects :/

"Wait, you just said you removed .gitignore, artisan, composer.json and composer.lock - wtf? Additionally those files are tiny in size."

Yes! Small files need a lot of time with FTP. They need more time than the bigger ones, especially if you have a lot of them - that's really simple! ;)

Lol what is this, 1990? People actually use ftp for updating their website?

"Lol what is this, 1990? People actually use ftp for updating their website?"

That's not special in my opinion...

On my own server with root rights, i use SFTP (Not the same as FTPS!! SFTP is SSH-based)

What do you use?

composer and git. git pull origin master. Boom. Installed.

On shared hosting, there is often no other way than to use plain old FTP... i never said i like that...;)

Then you don't truly "have root rights" or you could do whatever you wanted. You don't have shell access?

No, i don't think i have (at least limited - never root!!) SSH access on my shared hosting provider, maybe i need to ask their support... but i don't think so...

You can start by deleting your node_modules and vendor folders.

Now go through your package.json and composer.json and remove any packages you're not using.

Run npm install and composer install now. You'll only pull in the packages that you've left in the package and composer files.

If you're not using database migrations or seeders, you can remove the database folder.

In the config folder, you can remove any configuration files for things you're not using. For example, if you're not using email, you can remove mail.php.

In the resources folder, you can remove any file you aren't explicitly using.

In the routes folder, you can remove any file you're not using. For example, if your app doesn't have api routes, you can delete api.php. This will require editing your RouteServiceProvider to stop trying to load it.

In the app folder, you can remove the Console folder if you don't want to use console commands.

In the app\Http\Middleware folder, you can remove any of the middleware files you're not using.

In the app\Http\Controllers folder, you can remove any controller you're not using.

In the app\Providers folder, you can remove any provider you're not using. This will require editing config\app.php to stop trying to load these providers.

This is all a terrible idea and won't save you much space at all, all the while making your app a complete fucking pain to work with. Have fun.

"Do you realize how much easier updating would be with composer."

One day i will try it, when i have the time.

It probably takes you longer to do all of this than it would to just use composer to manage your dependencies.

@36864: "Laravel lite" or something like that? ;) No, that's not really my question, but maybe a good idea, who knows?

"Laravel lite"

You mean Lumen?

You can also just zip it up, upload the single zip file, and unzip it on the server.

@jmar83 Firstly, the files you are deleting are key files. In relation to deployment, as long as you have SSH access you can still deploy your site properly (certainly better than uploading via FTP *** shudders***).

Deploying via FTP is just plain wrong. Git is the correct way if you have git on your server.

You should also try deployer.org or https://github.com/git-ftp/git-ftp

However, the best solution is a proper server or host that supports git (plenty of shared hosts increasingly do).

You could also create a patch file using git diff and pipe that to the zip program. You'd be left with a zip file containing the changed files only. You'd run a command something along the lines of (i.e. assuming you wanted the difference between the master and production branches):

git diff --name-only origin/production..origin/master | zip patch_$(date '+%d-%m-%Y-%H-%M-%S').zip -@

@Cronix Or if using Forge I can just push to master :) For none Forge sites I use https://laravel.com/docs/5.6/envoy

This thread is so funny.

If you are really stuck with shared hosting, use composer locally to manage your dependencies and then upload your project once it is working and tested.

Use an FTP client that supports sync so that only changed files are uploaded each time

If that does not work for you, and you want to stick in the dark ages of php development then don't use a framework