My understanding is that bootstrap/compiled.php is auto-generated by running php artisan optimize, and is only intended for performance gains on production servers. Therefore it shouldn't committed in version control.
Am I correct?
Correct - it should not be included in version control.
Laravel excludes this file by default in the .gitignore file included in the framework root:
.gitignore
/bootstrap/compiled.php
...
Related
I'm developing my own gatsby.js theme (actually I've forked and modified another theme, then created new npm package for it). When I change any theme file in node_modules, for example footer.js, I don't see any changes while running gatsby develop until I delete cache with gatsby clean. In the past (2 years ago) when I was making first changes to my npm module, everything was updating as it should. I must also mention that I've cleaned node_modules and updated all dependencies with yarn to the latest available versions.
For example, I'm making this change:
<p className="text-lead"><b>Last modified</b> {lastUpdate}</p>
to
<p className="text-lead"><b>Last change</b> {lastUpdate}</p>
Then gatsby develop detects change:
success onPreExtractQueries - 0.004s
success extract queries from components - 0.128s
success write out requires - 0.003s
success Re-building development bundle - 0.198s
success Writing page-data.json and slice-data.json files to public directory - 0.014s - 0/1 73.40/s
But I see no change in the browser window until I run gatsby clean.
Here's part of my gatsby-config.js at root project folder:
...
plugins: [
{
resolve: "#arturthemaslov/gatsby-theme-intro-maslov",
options: {
basePath: pathPrefix,
contentPath: "content/",
showThemeLogo: false,
theme: "gh-inspired",
},
},
...
Also, I've noticed this warning when running gatsby develop:
warn The #arturthemaslov/gatsby-theme-intro-maslov plugin has generated no Gatsby nodes. Do you need it? This could also suggest the plugin is misconfigured.
Maybe that's something to do with this problem? I've also tried ghosting parts of theme plugin by putting theme files into root src folder, but no luck.
Reason why it isn't working is because you shouldn't be modifying anything in the node_modules directory and when you:
I must also mention that I've cleaned node_modules and updated all
dependencies with yarn to the latest available versions.
You just reverted or updated every dependency within the node_modules directory and if you updated to the latest you need to go through every dependency and see if you have any conflicts which you likely do.
Do note you're also using a theme with Gatsby "^2.20.12" and Gatsby is now on version "^5.2.0".
You also mentioned in the comments you're updated the NPM package while the repository source code is dated a few years. Do not think this is a good approach and you should look at building a release and using the Github Action NPM Publish
A quick question:
which files or directories from Laravel 8 needs to be transferred to a production system or Muße the entire files and directories?
Well, yes, you have to move all the files including the vendor directory which has all the php dependencies (unless you can run composer install in production, in that case there's no need to upload the vendor directory). If you have local logs and cache in the storage directory, you can omit those.
You will also need to create a new .env file for production.
And, if your are using JavaScript with Laravel Mix, you don't need to upload the node_modules folder, only the compiled js or css files.
I was looking at https://yarnpkg.com/lang/en/docs/cli/policies/ and it seems like a good idea to use it to allow my team to easily be on the same yarn version. However, yarn policies set 1.18 downloads the full yarn release into .yarn/releases (a 4.5mb js file) and sets a config entry in the repo's .yarnrc file.
It feels weird to check in this 4.5mb yarn executable, but if I don't, my colleagues are not going to be able to run yarn, because the entry in the .yarnrc won't exist on their system and it's not magically downloaded...
So, is it best practice to check the .yarn/releases folder into version control?
Yes your assumption is correct, you check yarnrc and the actual yarn JS file into source control.
I have multiple projects with very little space to keep.
since most of them uses nearly same packages (only 1 uses phpexcel and the other one swiftmailer ) and vendor folder required biggest space on laravel.
I thought maybe I could use same vendor folder for every of them.
I actually messed with autoload.php and some other config files however I couldn't make it.
simply I'll put vendor folder under public_html and create folder like project1 project2.
under those folders I'll put everything about my projects except vendor folder and then make them subdomain.
Short answer:
You can't.
Long answer:
/vendor folder is not just about packages, you also have in there vendor/composer folder, where your application classes names are stored for autoloading purposes. Everytime you run composer dump-autoload, Composer changes the content of some files there. Take a look at the vendor/composer/autoload_classmap.php file, you'll see that some of those classes are from your own project.
Workaroud:
Please note that I don't see a thing like this going well, but you can, actually, create a blank project, just for package downloading and symlink all packages from all your vendors folders to that one. It's a lot of trouble for a little gain. But it's up to you, of course.
Source: http://www.wenda.io/questions/2416709/laravel-4-1-vendor-directory-config.html
edit composer.json
"config": {
"preferred-install": "dist",
"vendor-dir": "../vendor"
},
edit bootstrap/autoload.php file
require __DIR__.'/../../vendor/autoload.php'
edit bootstrap/start.php file
$framework = $app['path.base'].
'/../vendor/laravel/framework/src';
edit ../vendor/laravel/framework/src/Illuminate/Foundation/Console/Optimize/config.php
$basePath = $app['path.base'].'/../';
then run composer install, you will find vendor dir created ../
php artisan optimize -v --force
Generating optimized class loader
Compiling common classes
in a fresh silverstripe installation (3.0.5) there are many files where I wonder if I will ever need them or what their purpose is... so what I would like to have is a clean silverstripe installation and delete all unnecessary files/folders.
For what do I need these files/folders?:
phpunit.teamcity.mssql.xml
phpunit.teamcity.postgresql.xml
phpunit.teamcity.sqlite3.xml
phpunit.teamcity.xml
phpunit.xml.dist
test.php
web.config
vendor
many thanks for the clarification.
Florian
PHPUNIT / TeamCity
phpunit.teamcity.mssql.xml
phpunit.teamcity.postgresql.xml
phpunit.teamcity.sqlite3.xml
phpunit.teamcity.xml
phpunit.xml.dist
those are files used to configure php unit and team city (team city is a continuous integration software by jetbrains https://www.jetbrains.com/teamcity/)
(if you don't use teamcity, you can safely delete this files)
Web Server Config
.htaccess
this is the configuration file for apache web servers (if you don't use apache, you can delete this file)
web.config
this is for Microsoft IIS web servers, it is the equivalent to the .htaccess (if you don't use IIS as web server you can delete this file)
GIT (Version Control System)
.git/
.gitignore
.gitatributes
if you don't use git, you don't need them
Composer
composer.json
vendor/
the composer file holds information of php dependencies and where to get them.
the vendor folder is the folder where composer installs its dependencies
(composer is a php dependency manager which I can really recommend http://getcomposer.org/)
(if you do not use composer, you don't need them)
PHP files
index.php
fallback file in case mod_rewrite or the ISS equivalent is not working
install.php
the installer for SilverStripe, this file should be deleted after you installed SilverStripe
install-frameworkmissing.html
part of the installer
behat
behat.yml
I can't say much about behat because I don't use it, here is a quote from the website (http://behat.org/): "A php framework for testing your business expectations."
All I can say is that you can delete the file if you don't use behat
Other
test.php
no idea, I have never seen this file
README.md
obviously the readme file
CONTRIBUTING.md
a info file containing information on guidelines for contributing back to SilverStripe
Makefile
build.xml
Can't exactly say how to use those 2 files, but unless you do use them, you can delete them safely
tl;dr
the only files you really need is one of those 2:
if you are using apache (linux and mac but also windows) then you need to keep .htaccess
if you are IIS (windows server) then you need web.config
and the index.php if mod_rewrite is not available on your server
all other files are just for 3rd party software the core developers use