【PHP】Laravel【フレームワーク】 Part.4
レス数が1000を超えています。これ以上書き込みはできません。
テンプレ追加修正お願いします
Laravel
ウェブ職人のためのPHPフレームワーク
本家
https://laravel.com/
git
https://github.com/laravel
動画チュートリアル(英語)
https://laracasts.com/
日本語
http://laravel.jp/
書籍
Laravel リファレンス[Ver.5.1 LTS 対応] Web職人好みの新世代PHPフレームワーク
Laravelエキスパート養成読本[モダンな開発を実現するPHPフレームワーク！] (Software Design plus)
※前スレ
【PHP】Laravel【フレームワーク】 Part.3
https://medaka.5ch.net/test/read.cgi/php/1574216148/ Laravel本家とそのgitリポジトリ、あとはLaravel APIぐらいで十分だと思う。 折角スレ立ったからここのスレ民に質問だが、ふだんLaravel関連の最新情報を得るために、どんなサイト見てる？公式ページやその翻訳サイト以外で。 >>6
laravelに限らずOSS系はこれしかない 日本はIT後進国なんだから、日本人が書いて日本人が読む本なんてもう相手しちゃダメだろ
公式一択 みんな公式とGitHubぐらいしか見ないのか。俺はredditあたりはLaravelの実務的な話がでてくるから、たまに見てる。 CakePHP関係も書籍はでないし、
PHPはもう廃れるのかな そもそもFWの書籍自体PHPに限らずそんなに無いでしょ。 ポンポン新バージョン出て追い付かないし商売にならんだろ >>15
既存プロジェクトのlaravelのバージョンが勝手に更新されるのか？大変だな >>15
常に自分にとって使いやすいバージョンを使い続ければ良いんじゃないのか？
最新版使わなきゃいけない決まりなんて無いだろ
最新版に入ってるセキュリティフィックスが必要なら自分で保守しなきゃならんけど バージョンも今後は半年1回じゃなくて1年1回になるからね。少しは落ち着く。 アップグレードしたら動かなくなるようなものはいらねえ それだとPHPも使えないのでは？あれも破壊的変更しょっちゅうやってるぞ。 でも、PHP5の知識で7扱ってもなんとかなるじゃん いい意味で枯れて欲しいよな
遊びで開発してんじゃないんだからさ 素直にLTSだけ使っとけばいいやん
開発側だって遊びじゃないし、何十年もサポートとかは無理 むしろLaravelほどビジネス色強いフレームワークは珍しいと思うけどな。作者のテイラーさん、1年で10億ぐらい稼いでたはず。
Laravelをガンガンアップデートしているのもユーザー側のニーズに応えるためって意味合いが強いのだと思う。
特に8でLivewireとTailwindCSSに切り替えたのはやりすぎかなって思ったけど、次期バージョンのRailsもLivewireライクなHotwire導入してTailwindCSSにするらしいから、ある意味トレンドの先取り上手いなと感心したわ。 Livewireってなんだろうと思ってぐぐったらべんですね！
このスレ見てるだけでも勉強になります！ cloud runとかその辺のサーバーレスで動かしてる人いる？ クエリビルダとeloquentってどっちを使うのが定番なのでしょうか？ 簡単なのはできるだけエロで
複雑な検索の場合だけ生SQL書いてる リレーションシップで取得可能かつクエリもパフォーマンスに影響が出ないものならeloquent。それ以外はクエリビルダ。 Laravel 8の書籍がないのは何故なんだ！！！！ >>38
変化が目まぐるし過ぎて著名な著者も安定するのをちょっと待ってるんじゃね？ 8って今年の9月までだっけ？
今から使うなら6のほうがよくない？ 9だか10だか次期LTS版が出た時の変更箇所とかを考えれば最新を追うのもそう悪くないと思う
ただUIはjsプレームワーク使ってる方が変更に対応しやすいがな CakePHP2->3の地獄を経験したものにとってLaravelのメジャーアップデートなど赤子よ。 >>43
そりゃcakeの2.0から3.0で4年も開いてるし >>40
8のサポートは1年伸びて、不具合サポート期限は6より半年長く、セキュリティサポート期限は6と同じだぞ。つまり今から開発するなら8以外の選択肢は存在しない。 >>43
今も保守で2使ってるけど、2で十分な気がしてる DB定義はマイグレード、初期データはシーダで作るとして
開発後の運用時のデータパッチ(データの不整合を直すとか)ってどうしてる？
昔ながらのやり方でデータパッチSQL作ってデータパッチ前後のDBデータダンプ取るとか？
シーダでデータパッチ処理作るのもlaravelとしてなんか違う感じがしてる artisanコマンド簡単に作れるからそれで作ればいいんじゃないの？ たしかにartisanコマンドはデータパッチ用に合ってる感じがする。
laravelタスクスケジュール用にしか思って無かった 俺もデータメンテ用のartisanコマンド作って対応してるわ。 全てのViewで利用するサイトのタイトルなどを変数に入れて使いまわしたいんですけど
configディレクトリの中のどのファイルに書くのが適してますでしょうか？ configじゃなくてルートディレクトリの「.env」 >>53
環境変数化したところでどのみちconfigでキャッシュするよ .envって本番と開発の環境分けるためだけに使うものだと思う .env推奨するやつとか、まじLaravelイチから勉強し直してほしい。まさかと思うけど、.gitignoreいじって、.envをリポジトリにアップできるようにしてないよね？ configにmaster.phpとか追加して書くかな
環境によってタイトルがかわるなら.envだけどそうじゃないなら.envは使わんね サイトのタイトル？
ならconfig追加しなくてもapp.phpのnameがそれに当たるんじゃね？ APP_NAMEは確かセッション名にも使われるから、タイトルタグに突っ込みたいような日本語だったら別のconfig作っちゃうな そうか、app.name は物理名向けの設定になるのか、論理名は別に作ったほうが良いね
なら、
app.label
app.title
site.title
global.site_name
…
まぁそんな悩む問題とも思わないが やったことないけど、app.nameをhogeとするなら、bladeの出力は__(hoge)と書いておき、langでディレクトリにja.json作って、hogeの和名称を定義する方法も選択肢としてはありなのかなって。 みなさん、サイト全体で使う値はどう管理されてるんですか？ >>57
symfonyは.envが普通にgitの管理対象に含まれているな >>66
Laravelってエラーメッセージ出るっけ？
俺の環境だといつも白い画面になるけど LaravelってAPP_NAMEとかは.envにいるくせに
なんでタイムゾーンなどの設定はphp直書きなんだろうか Laravelってリロードで多重POSTし放題なんだな
csrfトークンで対策してるのかと思ってたわ bladeだの二重ポストだの聞くけど、phpで画面描画してるとこ結構多いのか >>71
そもそもcsrfトークンで二重POST防止できてしまうのは単なるcsrfトークンの副作用に過ぎ無いので、そこ勘違いしちゃダメよ。csrfトークン使ったら破棄しなきゃいけないなんてルール存在しないので。 よくLaravelを使ったWEBアプリの案件に外注として参加することがあるけど
体感７割は画面表示にblade利用しているね laravel使うなら他のテンプレートをわざわざ取り入れるコストもったいないもん 意識高杉君がいるとtwigとかsmartyとか入れるんだろうけど それとリロードで多重POSTしちゃう実装が許されるのは新人のうちだけだぞ。POSTメソッドでviewをreturnするとか無いわー。 たぶん>>72はjsフレームワーク使ってねーの？て尋ねていると思うんだ。 csrfトークンがPOSTの多重送信まで面倒見てほしくはない >>71みたいなレベルに止まってるやつ結構居そうで震える。 リロードで多重ポストってリダイレクトすらしてないのかな
たしかにこの手のをガチガチに防ごうとするとそこそこの手間はかかるけど 多重ポストってlaravelだとガードかけるの難しい気がする
symfonyやcakephpだと多重ポストガード用の機能がフレームワークに備わっていたけどんどこどん 普通にやればいいだけだから難しくはないけど面倒臭い
Laravelのような高機能フレームワークがデフォでサポートしてないの意外 >>81
レベルに止まってるって何だよ実装できない初心者と思われたのかな
昔は自分で実装するのが普通だったが、最近はFWでサポートしてんのかなーと思っただけ > phpで画面描画してるとこ結構多いのか
>>76
それもphpじゃね？ >>85
違う。csrfトークンの実装を理解していない、POSTメソッドでお行儀悪くviewをreturnするってのは、新人までって話。つまり素人に毛が生えた程度のレベルってこと。 リロードで多重ポストはリダイレクトでいいんだけど
submit二度押しはフロント側で対処しているくらいだな
問題になることはないけど、なんだかしっくりこないってのはある ユーザーは多重POSTした事実を意識してないので、エラーが出ても困るだけ。だからcsrfトークンの破棄して副作用起こすような標準機能は俺からしたらただのバグ。
システム側で既に登録済みなら何事もなかったかのように完了扱いにするのが正解だけど、実装コストに見合うことはまず無い。て考えると予防としてフロントでカバーするに止めるのが賢いんじゃね？ >>74
bladeでいいやんtwigとかsmartyとかより使いやすいわ >>87
それだとリロード時は防げるけど、ブラウザで戻ってもう1回送信で多重ポストできちゃうじゃん
そういうの防ぐためわざわざワンタイムトークン実装してたわ >>91
まず多重POSTは意図せず発生した事故であるという前提で防ぐから、リダイレクトやフロントの予防措置で十分。
故意に画面を戻って再投稿するようなケースは、一般的な多重POSTのユースケースとは異なるてのが俺の認識。
前置きはこのぐらいにして、実際そういったケースでの対策は要件によって異なると考えている。
例えば、少し内容を改変して何件もサクサク投稿することがありえるコンテンツでは、最初の投稿をハッシュにしてキャッシュし、次の投稿のハッシュとぶつけて一致した場合だけエラーにするみたいな処理が望ましいかったりする。 というかワンタイムトークンなどサーバーサイドで予防機能を実装していることは、POST時にリダイレクトせずviewを返して良い言い訳にはならないので、ちゃんと実装してくれよな。
外注先がそんなの納品してきたら即リジェクトするわ(実際過去にしてた)。 まじかー俺逆の認識してたわ、リダイレクトする方が手抜きでお行儀悪いと思って初開発時から自力でワンタイム実装してた
教本なんかがPOST後に最初の画面にリダイレクトするのはサンプルだから簡略化してんだと思ってた
10年以上Webプログラマで食ってるがやはり自己流はいかんな >>89
バグだと言い切れるならissue立てて問題定義してこれば？ >>95
Laravelは破棄してないぞ。話についてこれないならROMるのがオススメだぞ。 >>90
ここで引き合いに出されたのはjsフレームワークだろ
twigやsmartyなんてそれこそ使われないだろ >>98
トンクス、余談だが俺の場合最初のWebアプリがガラケーのソシャゲだったのがよくなかった
あらゆるチートに対抗するためリロードや不正遷移対策ガチガチにしていた思い出
ガラケーはJavaScript使えない時代だから全部サーバーでやってたし >>100
それでいいんじゃないの？
想定してない画面遷移はそもそも想定外なんだから、想定外が起きないようにガチガチに制御するのは普通だと思う。
逆に許容できるケースのほうが珍しいんじゃないか？ みなさん二重にPOSTされてしまった時の対策ってどうしてますか？
やっぱりボタン押されたらJSでボタンを非活性にするほうがいいんですかね 使わないとテストできないのでは？別の選択肢としてPestもあるけど、わざわざインストールしないしねー。 自動テスト使わないとリファクタリングしにくいもんね。
Laravel本体はテストコード無いけどSymfonyとかはテストコード入ってるね >>107
コンポーザーで入れたらテストコード入ってないよ ぶっちゃけ仕事で作るプロダクトはテストコード書いたことがない
客がそこまでの予算出さないからな
こっちは納品して終わりだし、納期もカツカツでテスト書く時間がない、たまには書いてみたい >>108
Laravel本体にテストコードが無いという指摘はどういう問題につながってるの？まさか、Laravel本体のテストも手元で実行したいのか・・・な？ >>110
Laravel本体にテストコードが無い
じゃなくて
コンポーザーで入れたLaravel本体にテストコードが入ってない
ってことだよ。適当に流しときなよ >>111
そういう話では無いでしょ。>>106も踏まえての話だから。そもそもComposerでもLaravel Installerでも本体のテストコードなんて入ってこないよ。
なのでコイツは何言ってんだろ？てことで尋ねているのよ。 お前らってLaravelをバックエンドにしたときフロントエンドってどうしてる？
laravel-mixで構築して同一プロジェクトに含めてる？
それとも@vue/cli等フロントエンドJSが提供しているツールでフロントエンド用の
プロジェクト作ってる？ >>115
後者
laravel-mix使うメリット無いわ
あれ使ったらフロントとバックエンドを強制的に同じサーバーで動かす必要あるし >>116
>フロントとバックエンドを強制的に同じサーバーで動かす必要あるし
小規模プロジェクト一人でやってるからウチはそっちの方がいい SPAはフロントとバックを分離できるのがメリットだからlaravel-mixは使わないなー
>>117
同じサーバーでも動かせるよ 基本的にはLaravel-Mixを使うのが普通だね 何か海外でlaravelの.envを読み取るツールがあるらしくて
.envに記載してるメールのID、PWを抜かれてSPAMに使われてるみたいです
APP_ENV=trueになってると狙われるそうです >>121
君の狭い世界では普通なだけで、その他大勢の中では普通とは限らないのでは APP_ENV=trueって何だよ
APP_DEBUGじゃなくて？ >>126
この脆弱性はAPP_ENV=trueであってる
もう修正済みだけどissuesを見るんだ >>124
「メールのID、PW」とは？
SMTPサーバーのユーザー名とパスワード、であってるのかな？
>>128
君は>>124と同じ人？
いつ頃のバージョンで修正されてるの？ このスレよく虚言癖の来るからあんま相手にしないほうがいいぞ
前スレも「laravelはjsonの取り扱い方に脆弱性がある」とか一切ソース貼らずに騒いでるのやつがたくさん（一人の自演？）居たし ホントだ、issues見たけどそんなのないや
デマ流して何がしたいんだよそういう病気なのか APP_ENV=trueとか言ってるエアプの書き込み相手にするのは時間の無駄。 124の書き込みをしたものです
すみません、
APP_DEBUG=true
の間違いでした
laravel smtp crackerで検索すると海外の
記事が出てきます >>129
smtpサーバーのid.pwであってます
ただ.envの中身をスクレイピングしてるみたいで
データベースのid.pwやAWSの秘密キーなども
取得できるようです それってignitionの脆弱性利用したやつかな？いずれにせよ外からアクセス可能なところに、APP_DEBUG=trueのシステム晒すような雑魚は、ここには居らんから問題無いと思う。 本当だ、これかな
https://laravel-news.com/laravel-smtp-crack
APP_DEBUGがtrueかつ、公開ディレクトリに.envを置くのはSMTPの認証情報だけで済まないレベルで危ないと思うんだが、逆にそれだけで済むんだな。 公開ディレクトリに.envを置くって状況が想像付かんのだが
どういう理由でそういうことになるんだろう Laravelは知らんがcakeはレンサバとかのwebrootにしかファイル置けない環境でも動かせるようにhtaccessが用意されてたな >>124
それURL構成をexample.com/app/public/みたいにしてる場合じゃねーの？
一個前のスレにもそう言うヤツ居た気がするが publicディレクトリの中に置かないのにどうして読み取れるの？ >>140
Webサーバーで/をapp/public/にマッピングするのが昨今一般的なやり方だが
未だに
/var/www/html/app/public/
や
/usr/share/nginx/html/app/public/
にプロジェクトを置いてデフォルトルートからサブディレクトリにアクセスしてるんなら
ザルとは言わんまでも〜/html/app/ディレクトリの存在は筒抜けじゃね？ >>142
そうなんだよな、それをやったら.envどころかプロジェクト全体丸見え
特殊ツールなんていらんしsmtp crackどころではない全情報取れる laravelはサブディレクトリに設置する前提ではないので
運用方法を間違えてる人の人的ミス .env絡みで別の話だけど.envをソース管理にコミットする？
しないのが普通だろうが俺は.envで管理する情報追加の履歴も取りたいからコミットしてるんだけど githubとかの公開設定ミスったら終わりだぞ
そもそも.envは環境によって違うし
設定例として履歴残したいなら.exampleでええやん
今は機密情報を本番サーバーに置くことすらしたくないと言うことで、実行時にシークレットマネージャーとかから取得する時代だしね symfonyは.envもgitの管理対象に含まれているようだけど
大丈夫なのかな リポジトリに置くわけない
ソースコードとは別のドキュメントにして残す symfonyの場合は.envが管理対象に入っているけど
その.envの内容を.env.localで上書きできるから
本番設定は.env.localに書いて.env.localは管理対象から外すんだよ >>152
は？
本番設定は.env.productionに書けよ…
.env.localに本番設定書いてるプロジェクトに遭遇したら逃げ出したくなるわ GitHubの公開設定ミスる事ってあり得る？
private以外使うこと一生に1度もないわ クレデンシャルファイルを例えprivateであってもリポジトリ管理するの意味がわからん。セキュリティレベルが本番環境と同じレベルて保証があるならともかく。 .envをコミットすると書いた者だが本番用のパスワードやシークレットキーをそのまま書いてるわけではない
コミット時はテスト用またはダミーの情報を入れておいて、
本番環境にデプロイ後それを本番用に書き換えるという運用をしている >>156
それなら.env.exampleで良くないか？わざわざLaravelの.gitignore編集して、.envもコミットされるようにするって怖くない？ >>153
152じゃなくけど本番環境の.env.localに本番の設定書いてあると何かデメリットあるのですか？ あ、質問してから答えわかったかも
localというのを開発者のローカル環境という意味にとらえているということですかね
私はlocalはデプロイされているそれぞれのサーバー自身のことを指すと考えてました >>153
.env.productionは今や非推奨だぞ
symfony5だと.env.localが推奨されている >>153
symfony4までだったらその通りです FやN等色々な他社の開発案件に参加することあるけど７割は.envもgitの管理対象に含まれていたな .envをコミットすると奴いるとか、このスレはビックリさせられることが多いな .envコミットとかマジかよ
お前らレベル低すぎないか？ 多分このスレでそれやってるの1人だけだと思う。むしろそれ以外は批判する側。 自分でやってるのは1人かも知れんが誰かがやってるのを知ってるのは多数いる感じ？ VPC環境で動かしてる＆ソースはCodeCommitに置いてる業務システムだし pushできる開発者が全員.env見れるとかヤバすぎだろ... リリース担当が居ない(金かけられないから置けない)ような現場なら仕方ない このスレは零細勤め、個人事業主、趣味グラマーしか居ないぞ
大人数で開発できるような企業に勤めてるやつは極少数しか居ない 大人数で開発できる企業に勤めているけど、所属部署は俺しか居ないんだよなぁ。とりま、.envをリモートリポジトリにアップしたら怒られるぐらいには厳格な企業ですわ。つまり極小数派てことかしらん。 とはいえ.envの管理をどうするか？って問題もあるけどな
最適解ってあるんかね？
管理しないってのが最適解なのかな？ ここにいるバカ共は自分の頭で考えるって事をしないから、
「やってはいけません」とされていることをあえてやる奴のことを条件反射的に「ヤバすぎ」「レベル低すぎ」とバカにすることしかできない
ジャップランドの奴隷教育の被害者とも言えるが >>173
原始的なやり方としては、デプロイサーバーにローカルリポジトリ作ってそこで.envを管理するとか。あとは、システムの環境変数に定義して直接渡すとか。最近だとインフラ側が提供する専用のサービスみたいなのが選択肢でしょ。12appsあたりに方針は書いてあるぞ。
https://12factor.net/ja/ >>173
コンフルエンスにリリース担当やチーム責任者のみが閲覧可能なページを作ってそこで管理してる ハッカーがPHPの開発者になりすましてソースコードにバックドアを仕込んでいたことが判明 ハッカーがPHPの開発者になりすましてソースコードにバックドアを仕込んでいたことが判明 正確には「仕込もうとした」か「仕込まれた可能性がある」だよ
コードレビューで発覚したわけだから すみません。Laravelの脆弱性について教えてください
CVE-2020-24940の内容がよく理解できなかったのですが
簡単にいうとどういう脆弱性なんですか？ Taylor Otwellも前は普通に.envをコミットしてたけどIssuesで
.envコミットしないほうがいいですよって言われて管理対象から外したし
意外と.envコミットしてはいけないって意識している人少ないのかもな それは俺も知っているけどあれはTaylorがサンプルプログラムだから.envコミットしてもいいやって思って.envコミットしたんじゃないのかな？
実際のlaravel等の開発ではそんなことしていないはず Laravelは8になってから公式ドキュメントで.envをコミットしないでくださいって書いてあるな
逆に言うとそれまではなかった >>181-183
この人って病気なのかな
多分ずっと前から居るよね >>183
.gitignoreで除外してたよ？それを書き換えて.envをコミットしてたやつが一定居るようだけども。それで8ではマニュアルに明示したのかなって思ってる。 >>187
普通は181-183が同一人物による書き込みだなんて思わんよなー。なので、>>184は他のスレの誤爆なんじゃね？て思った。 >>181
どのissueで？
https://github.com/laravel/laravel
過去のブランチ遡って見てるけど.envがコミットされてるバージョン無いんだけど 普通に考えて.envをコミットはおかしい
symfonyには.envコミットが推奨されてるけどあれも頭おかしいと思う >>189
それは>>184に失礼だろ。誤爆の可能性が残っているうちは。誤爆じゃないならその時初めて病気認定して差し上げろ。 .envのコミット話がここまで盛り上がるとはな
他に盛り上がる話題もないし、これはこれでよかったかもw このスレには.envコミットしてる奴居るのかよ
とんだ魔境に来ちまった .envはパソコンに保存していたら壊れたとき困るから紙に書いとけって教わった このスレのお客さん的には.envはコミットすべきではないらしいが、
このスレの総意としては.envはコミットするべきなんだよね
Taylor Otwellも前は普通に.envをコミットしてたくらいだし（issueで指摘されて辞めたけど） 逆に.envをコミットしていない人たちってどうやって管理しているんだ？
.envに項目追加とか修正したときとか開発チーム全員に
同じ項目追加や修正作業をやってもらっているのか？ >>196
勝手に自分の都合の良いように話を捏造しないでほしいなぁ。テイラーさんがいつ、本番環境の.envをリポジトリに入れてたんだ？しかも内容はどうあれ.envに入れる行為は今は改められたんだろ？
あとスレの総意としては.envコミットするやつは糞だよね。自分の意に沿わない主張をお客さん扱いしないでくれ。.envをリモートリポジトリで管理することを支持してんの1人ぐらいしか居ないと思うんだが。 ギャーギャーキツい言い方してるのは少数(一人か二人)だと思う .envをコミットしてるバカってもしかしてデータベースのパスワードとか.htpasswdとかもコミットしてそう >>204
煽るのは勝手だけど、思考停止すぎで自爆バカにしか見えないぞ
.envをコミットしても問題ない環境なんて山ほどある とりあえずコミットしない方がいいということはわかった
いつまでも煽ってくる暇人が多いこともわかった
.envが発明される前は、CakeのConfig/database.phpみたいに普通にコミットされるのが当たり前だったな
せめてパスワード直書きを避ける工夫はいくつかあったけど >>205
思考停止してるから問題ないと思えるのな
あんたお花畑だろ >>206
.envをリモートリポジトリで管理しないってのは、.envがもともとの発想としてお手軽に「環境を定義する」ためのものなのセキュリティ的な観点とは関係ない。「ローカル」や「テスト」「ステージング」「本番」で定義内容が異なるケースが多いので、各環境ごとに作って共有しないってのが最近の使い方。
セキュリティ観点では、気密性の高い資格情報は、コードではなくて展開される環境に保存されるべきなので、そのへんが分かってないやつが騒いでるだけ 問題があると決め付けるのもまた、思考停止していると思うが
1人で試作品を作ってる場合なんかはあまり厳密にやる必要ないだろ
デフォルトで.gitignoreされてるからコミットする人は少ないだろうが、全ての人がGit使ってるわけではない 環境によって異なる設定ファイルをコミットから除外ってのは、大昔からみんなやってきてることだと思う
.envはそのために作られたものだからそれをコミットすると聞くと違和感があるのはわかる symfonyは.envがgitの管理対象に含まれているが
あれってセキュリティ上まずいような気がするけど管理対象に含めなければならない何かあるのか？
laravelは.envコミットしたらまずいから.gitignoreされているんだよね？ 明日で次期LTSのアンケート締め切りか
最終結果どんな機能順位になるんだろ？ このスレ定期的に数レス前も読まない奴が現れるけどなんなんだw
エラーログちゃんと読んでるのか？w 零細勤め、個人事業主、日曜エンジニア「「.envをコミットしても問題ない環境なんて山ほどある」」 >>215
これだよなぁ
このスレではこの層がノイジーマイノリティだよね
一部の例外を取り上げて、それがデファクトみたいな言い方するのやめてほしい 俺の関わった案件だと.envはコミットしてたな。
ただし.envに記載されている内容は社内からしかアクセスできない
テスト環境の情報だったけど
さすがに本番環境の.envコミットはなかった ノイジーマジョリティでは？このスレに大企業の奴なんていないだろ
基本PHPのオープンソースFWなんて小規模で使うもんだし オレは環境ごとに.env作ってるけど、別に.envコミットしても構わんだろ
機密情報とサーバ個別情報を環境変数で上書きしてしまえば実害ないはず >>219
環境変数使ったことない初心者がずっと騒いでるんだとおもうぞ
あほらしい つまりスレの総意としては.envはコミットするのが推奨で、
あとjsonも危険だから使うなってことでok？
.envをコミットするなって言ってる人って普段このスレ見てないお客さんだよね、どう見ても。
最近スレの勢いが増してるのがその証拠。 いやしない方がいいだろ、俺はしてたけどスレ読んでてそう思ったよ
絶対スンナ派と変に煽る奴と面白がって蒸し返す奴が出て来て荒れてるだけ >>221
お前は日本語勉強したほうがいい
要件によって左右されるものなんだから、スレの総意なんてあるわけ無いだろ
.envは普通はコミットしない(本来、環境ごとに設定するものだから)
ただ、コミットしても問題ない環境も色々ある
で、PHPerの総意としては、「セキュリティ気にするなら、サーバの環境変数を使え」 Laravelのお作法としては、クレデンシャル情報を書き込んだ.envはコミットすんなて話だし、それだと.envにどんな変数設定したら良いかわからんて人のためには.env.sapmleてあるわけだし。
内容がどうであれ、あえて.envそのものをコミットする理由なんて無いってのがスレの総意で良いんじゃね？ >>225
これかな？
https://laravel.com/docs/8.x/configuration#environment-file-security
でも、メインの理由は「開発者/サーバ別の環境設定が必要な可能性があるため、ファイルは、アプリケーションのソース管理にコミットすべきではない」だな。 .envをコミットするべきではないって、セキュリティの問題もそうなんだけど、それよりも開発しにくいでしょ
俺の環境で.envを変更してたのに誰かのコミットで変更されたら、ローカルにマージするときいちいち競合してたら絶対に面倒 >>218
小規模（1〜2人）開発者がほとんどだと思う根拠は？ >>226
セキュリティ気にするならこっちだな
https://laravel.com/docs/8.x/configuration#environment-configuration
> Any variable in your .env file can be overridden by external environment variables such as server-level or system-level environment variables. >>225
お前はマニュアルも読まないし、.gitignoreもわざわざ外す人って認識でOK？ >>218
俺は大企業に努めているわけではないが、少なくとも零細や個人事業主ではないなぁ
そもそも小規模開発の定義があいまいなんだけど、具体的人数だとプロジェクトごとのメンバーが5人未満くらいかな？
俺のところはプロジェクトによるけど大体15人前後くらいなんだけど、自分がそうだからって周りもそうだと決めつけるのは違うんじゃ？ というか、>>215の中小零細日曜エンジニアなら、.envコミットするっていう話が、どういう根拠に基づく主張なのか謎だわ。 .envコミットしているやつってlaravel-mix使ってそうｗ >>234
ものすごい偏見だしlaravel-mixのことも馬鹿にしてるレスなのにすごくしっくりきて草 >>226
DotEnvのドキュメント見るとFurthermore以降がわざわざ書いてあるのは悲しくなる
Laravel使うレベルのやつには環境変数に書き出すのが常識だと思ってたけど、このスレ見てそうじゃないって分かった そもそも抜かれて困る情報扱ってないしまっさらに消されてもクラウドの自動バックアップ機能で元通りになる 5人も投入して作るのは十分大規模だろ、そんなのここ10年ぐらいやってないわ、せいぜい2人
小規模って1人月ぐらいで作れるもののことだよ >>236
いや、このスレで.envをコミットしようとしているアホは1人、2人だろ。そもそもマニュアルも読まないなかーていうね。まぁアマチュアなら仕方ないけど、プロなら向いてないから転職してほしいレベル。 でも今までマニュアルに書いてなかったのに突然
.envはコミットしないでくださいってマニュアルに書くようになったってことは
.envコミットしているアホが結構多かったんだろうな .env.dev→ci用
.env.prod→本番
.env.example→テンプレ
.env→各個人固有環境（コミットしない）
APP_ENV環境変数指定で読むenv切り替えつつ、クレデンシャル系は書かないで環境変数でデプロイ時に指定のが普通だと思ってたわ そうやってアホアホいうから荒れるんだよ
自分とやり方違う人間はみんなアホなのかよ >>240
突然って言うけど、5.0の頃から書いてあるぞ >>240
調べたけどLaravel5.4以降のマニュアルではセキュリティリスクについて書いてあるね。5.3までは無かった。 >>242
自分とやり方が違うから責めているのではない。公式マニュアルでわざわざ「やるべきではない」て書いてあることをやっているから責めている。 公式マニュアルは法律でも何でもないぞ
どう使おうが使う人の勝手じゃねえか、お前に迷惑がかかるわけでもないだろ >>247
そのコードがお前だけのもんならそれで良いんじゃね？所詮そんなレスしかできない時点でアマチュアだろうし好きにしたら？ DotEnvのドキュメントを正とすると、そもそもLaravelの使用サンプルが間違い
DotEnvの正しい用法に寄せれば、公式にあるセキュリティリスクは無視できる
まぁ、セキュリティ要件やインフラ要件で左右されるもんだから、絶対的な正があるもんでもないけど >> 241 みたいな使い方がセキュアだろうね 言い方が悪かったから気を悪くされたみたいだが、「公式にこう書いてあるから絶対そうしなければならない」みたいにあまり縛られすぎない方がいいぞ
自分で考えて合理的ならそれでいいじゃん、他人にケチ付けたりバカにしたりするもんじゃないよ >>241
いやいや.env.example以外はコミットしちゃだめだろｗｗ
.env.dev(コミットしない）
.env.prod(コミットしない）
.env.example(コミットする)
.env(コミットしない）
が正解だろ そもそも.env.devや.env.prodって必要ある？それらを同じサーバーに置かないだろ意味ないから
開発用のサーバーには開発用の.env
本番用のサーバーには本番用の.envがあるだけだろ >>252
.envを履歴管理したいって要件が出てくれば、普通に >>241 みたいなやり方になると思うぞ
デメリットも特にないし >>254
他にどんな管理方法がある？
視野狭窄じゃない？ >>252
自動デプロイ回すのに
環境変数を設定する量は少なくしたいから
環境毎にenv分けて用意しとくのはよくあると思うんだが。
要らないenvが気になるならデプロイするときに除外すれば良いだけじゃない？ >>250
.envをリポジトリにコミットすることに関しては、合理的な理由なんてまったく無いよ。ここでの一連の会話読んでるか？
あと>>247の言い方からすると、お前は趣味でコード書いてるやつってことでOK？ バカの考え休むに似たりってことわざもあるんだから、まずマニュアル通りにやったほうが良いぞ。
今、Laravel教えているやつも、経験値ゼロなのにマニュアル通りやってくれなくて、無茶苦茶なコード書くんでスゲー苦労してる。 >>258
普通にバージョン管理の恩恵を受けると思うけど？
誰がいつどんな目的で変更を加えたのかわかるのは重要でしょ
監査とかで必要なケースもあるし
ってか、今話してるのはそういう流れなんだけど。。。 >>260
お前はGitHub使わないとバージョン管理できないのか？ローカルリポジトリて知ってる？ >>258
.env.exampleを使えってことなんだろうけど、そこまでちゃんとする必要なければ.env直の方が手間が減って合理的
あと趣味か仕事かは関係ない、開発者が1人かどうか、環境が1つかどうか等が関係してくるだろう
1人でLaravel開発する仕事しょっちゅうある >>261
これは思う
みんなGitHubをデフォルトと考えすぎだろ、それしか知らないニワカプログラマなのかと勘ぐってしまう >>262
はぁ？監査のためにGitHubのリモートリポジトリにコミットする合理的な理由が何か説明してみてよ。あとお前は>>247と同一人物？ 公式マニュアルや自分の知る方法だけが正しいと信じて守らない新人をバカにする
そういう輩が将来真っ先に老害になるから気を付けろよ >>263
関係あるだろ。趣味じゃないなら、新しくジョインするエンジニアのことや、そのコードを引き継ぐことも考えて標準に寄せるべきでは？オレオレ実装やオレオレ管理なんて、他人から見たらゴミだぞ。後生大事に思ってるのは本人のみだ。
まぁ、上のやつはそもそもマニュアル読んだ上で自分のやり方を選択したわけではないと思うけどね(笑) >>265
別にGitHubに限らんけど、チーム開発で変更履歴を証跡で残そうとするとごく普通の発想だろ
むしろ、ローカルリポジトリの履歴でどうやって監査対応するつもりなんだ？ セキュリティだのマニュアル以前に、純粋に不便だと思うんだが
.envコミットする人って、他の誰かがコミットした.envをマージする時どうしてるの？
マージするたびにローカルの変更をstashしているのだろうか。 >>266
守破離て言葉分かるか？自分のやり方で進める資格があるのはマニュアル通りやったことある人間だけだぞ。初めから好き勝手自分のやり方でやろうとするのは、ただのアホ。 >>269
>>241 読め。環境変数で読み込むファイルを指定する >>271
この人は.envをコミットしないと書いているよ
> .env→各個人固有環境（コミットしない） >>268
本番サーバーやデプロイサーバーにローカルリポジトリ作ってシェル書いてexportすりゃ良いでしょ。そもそも.envが監査対象になるときってあるの？どういう理由？ 俺以外も、.env直接使わないやり方の話してると思うんだけど、なぜ.envによる管理が合理的て未だに思い込んでるんだろ？ >>273
ローカルリポジトリ作っててソース管理するんじゃんｗ
何が言いたいんだよ ローカルにGitLab立てるとかでもええやん
俺は管理面倒だからやらないけど 荒れてるからスレの勢いが板でダントツ1位だｗ
いいぞもっとやれ >>278
それ解決できるのは、頑なに.env使ったほうが合理的とか言ってるヤツだけだからなぁ。実質不可能じゃね？ここで袋叩きにあってるせいか、適当な理由つけて自分を正当化するのに必死みたいだし。 >>281
じゃあやっぱり零細、個人事業主、日曜エンジニアの人がそう言ってるだけなんですかね？ >>283
その約1名は、監査監査言ってるからなぁ。そこまで監査にこだわるわけだから、それなりの規模のある会社の末端プログラマの可能性はある。 普通に考えて>>269みたいなことになる環境ではコミットしないのでは？ うちは中小未満零細以上って感じの会社だけど、Laravelのプロジェクトは1人でやらされる >>286
開発者が一人しか居ない以外のケースでそれってあるんですかね？
それ以外だと例えばどんな環境なんだろう… 開発者が複数いても実行環境が1つしかないってケースがあり得るぞ
うちも以前やってた
共通の開発鯖上で各人のディレクトリ分けて、DBは共通 ここまでをオレ主観でまとめると
・.envは環境定義用のファイルなので、実行環境ごとに異なる。基本的にリモートリポジトリでの管理からは外すのが快適
・.envをセキュリティ観点でソース管理から外すっていってるのはセキュリティ分かってない証拠。その観点で見たときには環境変数使う
・.envをバージョン管理したいのであれば各環境ごとのファイルを作って、環境変数APP_ENVで利用するファイルを切り替える
異論は受け付けるｗ >>289
> 実行環境が1つしかない
えっ、そんなケースもあるんですか！
1つしかないってことは、本番、ステージング、開発、すべてを兼ねてるんですか？
めちゃ効率的だし画期的じゃないですか！
まぁちょっと危ない気もしますが笑笑
マイグレーションとかどうしてるのか気になります笑笑 >>290
.env.exampleが抜けてるぞ
テンプレ管理目的でこれをバージョン管理する
俺は今まで.envをコミットしていたが今後そうするつもり >>291
開発中にちょっと構文ミスっただけで、本番はデバッグ用のスタックトレース出てくる状態を想像したら草 >>291
さすがに本番鯖は別にあります
開発鯖の中でディレクトリを分けて、
https://開発鯖ドメイン/開発者1
https://開発鯖ドメイン/開発者2
https://開発鯖ドメイン/masterの動作確認用
みたいにアクセスしてた >>292
いいね。お前みたいなのが居てくれると、ここでしつこく言った甲斐があるなぁ。 >>292 さんきゅ
まとめ直した
1 ..envは環境定義用のファイルなので、実行環境ごとに異なる。基本的にリモートリポジトリでの管理からは外すのが快適
2 .envをセキュリティ観点でソース管理から外すっていってるのはセキュリティ分かってない証拠。その観点で見たときには環境変数使う
3 各環境の..envのテンプレは.env.exampleを使用すると良い
4. .envをバージョン管理したいのであれば各環境ごとのファイルを作って、環境変数APP_ENVで利用するファイルを切り替える
4はもうちょっと突っ込む必要があるかなぁ。他のフレームワークでもよく見る方法だけど、Laravelでデメリットはないのか、実際に使っている人のコメントがほしい >>296
セキュリティの観点でいうと、やはりリポジトリに置かないほうが安全だと思ってしまったんですが、これやっぱり浅いですかね？
僕のところだと.envはignoreされてるので、ここで言うところの「コミットしない派」に含まれるんですよ。
だから新人の僕は本番のDBやRedisの接続情報、外部サービスの秘密鍵なんかは当然知らなくて、リリース担当者とマネジャーの人だけが知ってます。
その人たちは接続情報などは別のツールで管理してるっぽいです。
でも僕含めた他の多くメンバーは各自がDockerで用意すればいいだけなので困ることもないですね。
（もちろん.env.exampleは用意されてますよ）
で、それをignoreしてる理由は、正直ほかの皆のように深く考えたことなかったです笑
でも、その全員が本番のDBやRedis、その他にアクセスできると責任の所在が明確では無くなるのが問題だから除外されてるのかなって漠然と思ってました。
これはみんなの感覚で言うとずれてるんですかね？ >>297
個人的には浅くないと思うけどな
それぞれいろんな理屈はあるにせよ、セキュリティの観点は看過できないとは思う .envをコミットする人たちってもしかして.idea等IDEが自動生成するフォルダも
コミットしているのか？ >>297
セキュリティ観点で考えるなら、ちゃんと「何を何からまもるか」って検討しないと意味がない
Laravel以外も含む一般論としては、「.envとかconfigファイルとかに機密情報は記載せず環境変数で提供する」ってことになると思うけど、これはミドルウェアの管理者が接続情報を管理すべきって発想が根底にあるので、そこに乗れない環境であるなら自前のポリシーとガイドラインを設計する必要がある
昔は環境変数が主流だったけど、今はインフラやミドルウェアの仕様がかなりトリッキーなシステムもあるので、よりインフラ別な管理手法になって行くんじゃないかなぁ >>291
そんなケースざらにあるぞ
特に顧客側がサーバを用意する案件だと本番環境サーバしか用意してもらえないことがある
今までの個人的な感覚だと大学案件にそれは多くてテスト環境サーバも用意してほしいと言っても
予算だったり仮想ホストサーバのリソースの都合等でテスト環境は断られることが多い >>300
そもそもLaravelが.envをセキュリティを理由に管理対象外にしているのは事実だし、実際のところ不用意にクレデンシャル入りの.envをpushするエンジニアが居てたまにネタになってたりする。
お前の言ってることは正論だけど、その議論が成り立つほどLaravelを使っている奴らの意識は高くないので(中央値の問題ね)、.envを管理対象外にしておくことはセキュリティ観点から妥当な対応と評価できると思う。 >>302
300だけど、ぶっちゃけクレデンシャル入りの.envを管理対象に含めても、関係者以外に非公開であればセキュリティポリシー的に問題になるケースは少ないはずなんだよなぁ＾＾；
ので、.envをバージョン管理すべきかどうかの議論はセキュリティ観点抜きで、「環境ごとに用意されるべきものだから共通管理すんなよ」で良かったんじゃないかと思う >>300
「.envとかconfigファイルとかに機密情報は記載せず環境変数で提供する」というのはまた別の話だと思います。
それは一旦切り離して考えませんか？
今は論点が多分3つ4つくらいあって、こうだと思います。
- 論点A: .envをリポジトリで管理する是非
- 論点A-1: 開発の利便性における観点
- 論点A-2: セキュリティにおける観点
- 論点B: 機密情報を環境変数で提供することの是非
この論点Aと論点Bは近しい話かもしれませんが、同時に論じることってできないですよね？
論点Bを肯定するには、論点A-2が否定されている前提になると思うので。 零細勤め、個人事業主、日曜エンジニア、>>205「「.envをコミットしても問題ない環境なんて山ほどある！！」」 >>305
ナンダこの周回遅れ君。スレのみんなはステップ一つ上がってるぞｗ お前らどーでもええことで長いこと揉めてんなあ
ちゃんと動くもの作れているのかいな つまり話をまとめると、基本的に.envはコミットしちゃ駄目だけど、
俺みたいな小規模開発オンリーのエンジョイ勢みたいな場合はコミットしてもそんなに害は無いってことでいいか？ >>308
それで良いと思うよ
個人なら好き勝手にやればええ、責任取るのは自分なんだし
おれは個人でもコミットしないけどね >>308
そのやり方が普通であるかのように喧伝したり、他のエンジニアを巻き込むようなことをしないのであれば、好きにしたらええんちゃう。
まぁ俺も同じく個人開発用のリポジトリであっても.envはコミットしないけど。コミットする理由が無いので。 >>311
俺には面白かったけどなぁ
俺主観でもう一度整理した
1 .envは環境定義用のファイルなので、実行環境ごとに異なる。ので、基本的にリモートリポジトリでの管理からは外すのが快適
2 .envをセキュリティ観点でソース管理から外すっていうのは「機密情報は環境変数で管理するべし」ってベストプラクティスを知ったうえで判断する
3 各環境の.envのテンプレは.env.exampleを使用すると良い
4 .envをバージョン管理したいのであれば各環境ごとのファイルを作って、環境変数APP_ENVで利用するファイルを切り替えると快適
4はキャッシュあたりに落とし穴ありそうなので、経験者のコメントがほしいよー >>314
ね、頑なに.envを外したがる奴って意識高すぎだろw
細かいこと気にしすぎだし絶対童貞だろw 意識高いとか笑える
むしろ逆でコミットする方が意識高いと思うが >>315
結論は>>308-310あたりでもう出てると思っていて、それをわざわざ掘り起こして人格否定煽りはみっともないと思います。
頑なに「頑なに.envを外したがる」というのが間違いで、
このスレを読んでいる限り、外す人は
「私のプロジェクトでは外しますが、あなたのプロジェクトなら好きにしてください。おすすめしませんけど。」
というスタンスの方が多いと思います。（僕含めて）
むしろデフォルトで外れている以上、まず外す前提があって、拘りがあって.envをリポジトリに入れる。
というあなたのスタンスの方が、あなたがいう「細かいことを気にしすぎ」に合致しませんか？
ちなみに「クローンしたらすぐ動く」という意見もちょっと微妙で、
実際には、
・Dockerコンテナの作成
・パッケージマネージャでプロジェクトのインストール（バックエンド、フロントエンド共に）
・DDL/DMLの反映（マイグレーション）
という作業が "最低限" まだ残っているので、.envを入れたからすぐに動くというのは違うと思います。
むしろ「他開発で使っているポート番号が競合しているけど、環境ごとに変更できないから動かない」なんて問題も起きかねないと思います。
つまり.envを入れておくとクローンしてすぐ動くわけでもないと思いました。 .envコミットしとけばクローンしてすぐ動くじゃんとか主張しているやつは、vendorディレクトリもnode_modulesディレクトリも好き勝手コミットしてそう。 >>318
それなー。Laravelがあえて外しているものをわざわざ自分流にアレンジして管理しようとするっていうね。で、理由を聞いてもまともな答え返ってこない。 >>319
正解。Laravel本体とかnodeのパッケージに手を入れてるからリポジトリに含めてる >>319
メモリ1GBの鯖でcomposer動かしたら鯖が死ぬので使えないから、vendorもリポジトリに入れてデプロイに含めてる もしかして、サーバーに入ってgit pullすることをデプロイと呼んでいる？ >>324
手でgit pullと打つわけじゃないけどデプロイスクリプトがgitのmasterを引っ張ってくるようになってるから実質そう 基本本番環境は外部ネットワーク接続禁止だから
vendorもnode_modulesもコミットしてるな >>323
そんなことでサーバ死ぬ方がおかしくないか？
sawp切られてないとかじゃないの？ >>234
この発言全国の.envコミットチー牛にぶっ刺さりまくって草 >>327
swapも作ってるんだけどI/Oがアホみたいに遅いみたいで、物理メモリ切れると数時間鯖が死んだように瀕死になって再起動するしかなくなる
Lightsailでそうなるんだけど俺だけ？普通にCentOS7入れてるだけなんだが うーん。デプロイサーバーまたは手元のPCでデプロイスクリプト流すとcomposer installとか一連の処理を行い、そのあと本番サーバーにrsyncみたいなやり方もある。
だから、デプロイのためにリポジトリ管理するってのは違和感あるけど、実はそのほうがメジャーなのか？ >>330
今後はそんな風にしようと思ってる。やはりrsyncがよさそうだよな。
リポジトリから引っ張ってくるのとどっちがメジャーなんだろ。Deployerってのを使ったことあるがあれは毎回git checkoutしててファイルが多いと死ぬほど遅かった。 たまにはまともな技術の話しようぜ。お前らもうすぐリリースされるlaravel-octane使う？使わない？ laravel-mix使ったらダメなん？
laravel-mixって何だっけ 君たちパッケージマネージャー管理下のファイルをリポジトリに突っ込んでたのか
びっくり仰天だこりゃ Laravel-Mixは手軽でええやん
使える案件なら使えば良いと思うよ
何でもかんでも否定するのも良くないね >>340
当たり前だろ
まず.gitignore自体が俺のとこじゃそもそも存在しねーよ
IDEの設定ファイルもみんなで共有するのが基本だぞ そもそもGitなんて使ってねーし
.gitignoreをignoreしたったるわ >>342
いや後者は普通にあり得るけど(.editorcofgみたいなのもあるし)、前者はおかしいだろ。てか、何のためにlockファイルがあると思ってるんだ・・・。 そもそもvendor以下はcomposer、それ以外はGitなりSVNなりで分けて管理するっておかしいだろ
ソースチェックアウトしたものが動くという保証がなくなるじゃん
実際composerはメモリバカ食いするしエラー出されたらお手上げ、イマイチ信用できない 開発環境のPHPのバージョンすらも不明な状態なのにgitからチェックアウトするだけで必ず動くと思えるのはお花畑すぎる。それにお前のやり方だと、開発のみのパッケージとかどうすんの？ composerってそんなにメモリバカ食いなの？
php.ini触れない環境とかだと苦しいのか >>332を見ると1.5Gか無制限にしろと書いてあるな
memory exhaustedでFatal Errorは俺も出たことある つーかそもそも普通にcomposer使えない環境もあるんちゃうの
そういう場合自分でvendor管理してアップロードするしかなくない？ >>347
引数で使用するメモリは増やせる。あとたぶんここでcomposerガーて言ってる人は、composer2使ってない人。 「laravel-mix使ってそう」強すぎて禁止ワードに というか外部ネットワークからcomposerのライブラリやnodejsのライブラリ持ってこれない
本番環境だったら自分でvendorやnode_modules管理するだろ お前らってlaravelのキャッシュもコミットしてそうｗｗ そういう環境ではyum upateとかもできないの？ >>354
できないよ。外部ネットワーク接続禁止の案件はかなり多い
その場合自分でアップデートするrpmパッケージ一式を用意するしかない 殿堂入り：
JSONレスポンスは脆弱なので使わない
S：
vendor下のファイルをコミットする
本番環境が開発環境
一つの開発サーバー・DBをみんなでシェア
A：
.envをコミットする
.ideaをコミットする
B：
Laravel-Mixを使う
XAMPPを使う
C：
零細企業で勤務する >>356
これ1つでも当てはまる人に聞きたいけど、もしかして偏差値45以下の大学通ってた？ >>352
それだとリポジトリどうすんの？リポジトリはオンプレ型のgitlabとかsvnとかなん？ そもそもビルドサーバー分けるべきだと思うけどそれは置いておくとして、
アウトバウンド一切いじれないなら外部サービスのAPIコールするときやSMTPサーバーどうやって接続するんだろ
最低限DBやRedisにアクセスすることあるだろうし、
reCAPTCHAやSalesforce、Twilio、SendGrid、外部ストレージは割とよく使われると思うんだけど、そこだけはアウトバウンド許可するのかな？ vendor以下のライブラリってOS依存やアーキテクチャ依存とかは発生しないの？
コミットするとか考えたこともないから詳しく調べたこともないんだけれど >>361
バイナリじゃないただのテキストだからインストール環境に依存することは無いだろうね
ちゃんと確認したことは無いけども >>360
自分の大学案件の場合は当然外部サービスはすべてNG
SMTPサーバは大学が用意したものを利用するけど
そのSMTPサーバも学内に設置されている >>356
本番環境が開発環境はNだけど俺の経験上結構あった ここの住人は他フレームワークやったことないやつばかりの掃き溜めなのか？と
不安しか感じない記述だな
まあ、まともにプログラミングできるやつはLaravelなんかに利用しないんだろうが
ドヤってることの次元が低すぎて寒いというより読んでてつらい… ↑こういう書き込みをする奴が一番ヤバいのは周知の事実 情報量ゼロで謎の上から目線
職場でも嫌われてるんだろうな そもそもどういう環境でフレームワーク使ってるのかみたいな話が主なのに、他フレームワーク使ったことない奴らみたいな結論になってるのがすげー謎だわ。 >>356
え、バッドノウハウの宝庫だけど、このスレでは該当する人がゴロゴロ居るのか…？
素人とかだったら何とも思わんけど、金もらう立場でこれだとした、… >>366, 368
そいつはスレのみんなで育ててるミジンコだから、あんまり強い言葉で責めないで！
普段は、時代錯誤なこと言ってるのをにやにやしながら楽しめばいい
で、時々古い時代のことを書き込んでやると良い餌になるｗ とりあえずミジンコが「独身」で「無職」っぽいことはわかった >>370
そうですよ
このスレではスタンダードです Laravelの人気があるせいで初学者が多いねここ 煽りワードの中に「無職」があったので考察してみる
実際、最低限ここでの議論を理解できる程度の知識があって「無職」の人ってほぼ居ないと思う。
※ただし、かなり低次元な議論なので高度な知識とは限らない。あくまで無職ではないだろう、という程度。
「零細」というワードが効いてしまって、それ以下の立場を煽る為に架空の無職を創り出しているように見える。 >>361
PHPのバージョンおよびそのエクステンションとの依存はある。それ以外は無い。 >>374
そうか？どっちかというと、業務でLaravel何年か使ってるやつが多いと思うけども(書き込んでいる奴ら限定)。だからデプロイの話とかコミットの話で一触即発になる。初心者はそんなの気にしない。お前はどうしてそう思ったの？ >>377
374とは別ですが、僕は>>374と>>377の言うこと両方分かりますよ。
初学者が多いように見えるというのはすごく単純で、荒れた理由が酷いです。
.envやパッケージマネージャー管理のファイルをリポジトリに含めるとか含めないとか、そんなこと初学者間でしか荒れないと思います。
一方で、>>377が言うことも一理あって、初学者同士ではこの話題で一触即発にはならないと思います。何年か業務経験ある方も多いと感じます。
この矛盾はおそらくですが、初学者が無知を晒してしまったところ（先述の荒れた理由）を業務経験が中途半端にある方が、過度に馬鹿にしすぎてしまった為、初学者の方も頭に来たのだろうと予想します。
その結果、初学者と経験者の間で不毛な争いが起きていると思います。
ただ、ここで言う経験者の方も、そこまで熟練しているようにも限らないです。（ただ、.envをコミットすべきではないと、ごく一般的なことを述べただけなので）
つまり、このスレには初学者も経験者もどちらも居る、というのが僕の見方です。 > .envやパッケージマネージャー管理のファイルをリポジトリに含めるとか含めないとか、そんなこと初学者間でしか荒れないと思います。
俺はそうは思わないな。初学者はそんなこと気にするレベルに至ってないと思う。
あまりお行儀のよくない職場で経験を積んできた経験者が荒れてるのではないかな。
>>356で書かれてる
・vendor下のファイルをコミットする
・本番環境が開発環境
・一つの開発サーバー・DBをみんなでシェア
ってのは技術者が未熟だから起きるんじゃなくて、現場の環境だろ
鯖とDBをシェアして開発ってのは昔（Dockerとか流行る前）は普通だったから、逆に初学者はそんなやり方知らない >>356
laravel-mixがダメな理由とは？ >>378
業務経験がないやつが馬鹿にするから荒れたんだろ
君もあんまり理解してないっぽいけど、Ｌａｒａｖｅｌ案件って今すごい広い幅で使用されてる
例えば、デプロイ先がレンタルサーバなんてのもあるんだ
で、業務経験豊富なフリーランスの中にはそんな案件を2人月200万とかで売り切ったりもする
そうすると、ネットに接続できない環境と似たようなことをしなきゃいけなかったりするんだ
幅広い層で(無理やりも含めて)使用されてることが理解できてるやつは、原理原則を抑えた上で柔軟な対応を取ろうとする
できてないやつが公式の背景も理解せず荒らしてるだけだと思うぞ
まー「レン鯖でLaravel指定」はやめてくれって思ったりするけどｗ 荒れた理由は「公式のマニュアル通りにしない＝バカ」と決め付ける奴が1〜2名いて煽りまくったからだと思う
反省しろ >>378
いやいや、そもそも初学者同士じゃ.envの扱いの話題すら出てこないから。まして、.gitignore編集して.envやvendor配下をコミットしようとする初心者が居てたまるかよ。 >>382
違うぞ。公式のマニュアルすら読まずにオレ流でやってたからバカにされている。読んだ上で意思を持ってそうしてたら、まだここまで荒れなかったさ。 公式盲信して「.envはクレデンシャル入ってるからコミットしちゃダメ」とかいってるバカも荒らす要因だったけどな 前もマニュアルろくに読まず、mixやlivewireのアセットファイルはルート直下にしかおけないからLaravelはクソとか言ってたやついるからなぁ。 >>385
公式のマニュアル読んでない奴に、マニュアルをまず読めていうのは普通なんだよなぁ。そのアドバイスがマニュアル読まない人間からは盲信しているように映るんだな。勉強になる。 今度は荒れた理由探しで荒れているｗ
いいぞもっとやれ >>386
つまりnpm run devとかの使い方をろくに知らんヤツが言ってるってこと？ >>387
そうだな。
「.envはクレデンシャル入ってるからコミットしちゃダメ」とか言ってるやつは盲信じゃなくて、マニュアル読めてないやつだもんな
まず、ちゃんと読むところから教えてやらんとな >>116
固定のテストJSONを返すバックエンドと
バックエンドにパラメーターを送る簡易UIを用意すれば分業できるじゃん？ >>390
国語力が無いからそもそもマニュアル自体読めないって話ね。把握した。 >>389
そこまで酷いわけではない。
単にmixやlivewireのアセットファイルはconfigファイルで任意の場所に出力するよう指定できるんだが、そのやり方を知らなかっただけ。
テラテイルやStackOverflowで似たような質問している奴に回答がつかなかったから、できないと思ったらしい。 何が脆弱性につながるかわかってないから、jsonは無条件で安心だとか言い出すことになるんだよw >>394
.envをコミットするのは無条件で安心w お前らってconfig/app.phpもコミットしてそうwww.com え？app.phpってコミットしないのが普通なのか？
俺今までコミットしてた・・ app.phpはコミットするなよ・・・ .envコミットしているやつといいお前らちゃんとマニュアル読んでるか？ ここの奴らLaravelの運用については嬉々として話すんだけど、>>338みたいな技術的な話になると無反応になるのが寂しいわ。まぁまだリリースされてないからってのもあるんだろうけど。 .envコミットするのは正しい運用だと思うけどな
.envコミットしてないと本番環境の設定が管理できないだろ 407とかは、前スレでjsonは脆弱だって言って暴れてた人と同じだろうね そもそも.envて環境変数なわけで、Infrastructure as Codeて概念が浸透する前は、バージョン管理なんてしてなかったと思うんだが、なぜ.envに限って言えばバージョン管理が正解て話になるんだ？
意識高いエンジニアなら大体目を通している12factorsみたいなベストプラクティスでも、configとcodeは厳格に切り離せて言ってるんだよね。理由はconfigはデプロイする環境によって異なるから。
そういう意味でもLaravelのマニュアルにあるような.envの扱いは適切だと考える。
むしろ、ここで.envをコミットする運用が正しいて主張する奴はどんなドキュメントを根拠にしているのか尋ねたい。まさか長年の経験とかじゃないよね？ ということはほかの人がいってるconfig/app.phpはコミットするなというのは
12factorsだとベストプラクティスということですか？ 梅沢富美男「てめぇこの野郎…手だけでもうこんなにも大きくなってるじゃねえか、ええ？」シコシコ……
俺「ああ…すごく気持ちいいよ、富美男」
富美男が俺のものを、そのごわごわとした手で優しく包み込む。
程良い締め付けと心地良い温もりで、思わず口元が緩んでしまう。
梅沢富美男「バカ野郎が……こういうのはどうだ？チロチロ…」
俺「うぁ…くっ…！！」
富美男が悪戯に亀頭の先端をチロチロと弄ぶ。屈強そうな外見には似つかわしくない、丁寧で繊細な舌使い。
あまりの気持ち良さに、射精感がぐぐぐっと高まるのを感じる。
梅沢富美男「…可愛い顔しやがるじゃあねえかこの野郎…そろそろ仕上げだ。ジュルジュル…ゴプッ！グポポ…ジュルジュルルル！グッポ！ブブブ…！」
俺「ひぁああ…！富美男！富美男ぉお！ぐっ…！！」
富美男が俺の股下で激しく上下する。俺のものはてらてらと光沢を帯び、上下運動を繰り返す度に富美男の唾液と俺の精液が混じり合った、ひどく性的な粘液が滴り落ちる。
限界までいきり立った俺のものは、欲望の全てを富美男の口内に解き放つ。
俺「ああはあっ…！！はあっ！はあ…はあっはあ……！富美男…富美男良かったよ…」
梅沢富美男「…ゴクンッ！……はあっはあっ…てめぇこの野郎！こんなにも一杯出しやがってバカ野郎…腹ん中パンパンじゃねえか…！！…まだ出したりねえよな？」
俺「…富美男には全てお見通しか。敵わないよ、お前には…」
梅沢富美男「当然だバカ野郎…ここからが本当の夢芝居だ」
俺と富美男は、夜が明けるまで、何度もなんどもお互いを求め合った。 本番環境や検証環境の環境変数のバージョン管理をするというのは至極当然だと想いますが、
それを開発者全員がアクセス可能なgitリポジトリで管理するのはバッドノウハウです。
gitリポジトリとは別にバージョン管理をしますし、アクセス可能なメンバーは限られているべきです。
私の職場ではそれが普通です。 本業の片手間にプログラム作ってたらそれの専任者なんて置けないからね >>412
それらはアプリ内部のパラメータだから、12factorの言うconfigには入ってこないね。 laravel-mixを馬鹿にするレスもあったがlaravel-mixって使わないほうがいいんですか？ >>418
使っちゃ駄目ってことはないと思うよ
でもvue-cliで良いじゃんとは思うけど >>198
ぶっちゃけこれが正解じゃね？
みんななんでそんなGitに拘るの？ >>420
便利だからじゃね？
むしろsvnに拘る理由は何？ switch全盛の時代にファミコン持ち出して「ファミコンで良いじゃん。なんでみんなswitchに拘るの？」って聞くようなもんだよな
どっちが拘り強いんだか そういやちょっと前GitHubのソースコード流出問題みたいなのがあったが
国内大手企業辺りでGithub禁止令みたいなの出たところあるんかな？ 今どきsvnはないだろ
Mercurial出してくるならまだわかるが >>423
GitHub禁止はそれ以前から普通にあるだろ
そもそも、インターネットから切り離された環境が存在するんだし
あと、話題になった流出問題は、持ち出したコードを転職評価用にGitHub登録してみたってやつだったはず
雇われ人の利用範囲でGitHub禁止しても因果関係としては無意味かなぁ
個人での使用も禁止する！とか言っちゃうと、法律に引っかかるからそっちはないと思う 古いってだけでsvnディスる奴は多いが機能的には何も問題ないぞ
Gitじゃないと困ることって実はあんまりない、今だとGitに慣れてる人が多いから無理に逆らう理由もないけどよく知らずに「今時svnはないわー」みたいにイキるのはアホ
そんなんが面接に来たら落とす むしろsvnなんかありがたく使ってる会社になんか入りたくないし、
そういう面接官はありがたい >>426
オレは「今時svnはないわー」派なんだけど、Gitが良いっていうよりGitHubが良いからって感じだな
特に最近のGitHubのCD/CIツール群のコスパが良すぎる
自前で管理サーバ建てられる規模ならどっちでもいいだろうな
ただ、このスレで「今時svnはないわー」って言ってるのは例のミジンコだぞ
なんの背景もないからほっとけｗ >>426
ネタのようにも見えますが、あえてマジレスしますと、svnはgitに比べて普通に機能が劣ってます。
・svnのブランチは不便です。ブランチを切るのがgitでは一瞬ですが、svnではすごく時間がかかります。
・ブランチ同士のマージはコンフリクト起きすぎです。gitのマージがいかに賢いものか分かります。
・svnのブランチはgitのブランチとは全く異なってて、「ブランチ」という名前が一緒なだけで、機能としては全然違います。
・プルリクエストの概念すら無いのでレビューもしにくいです。
他にももっとありますが、この辺にしておきます。
これらは1人や極少人数の開発ならそこまで大きく問題ないかもしれないですが、人数が多ければ多いほどこの問題は顕著です。
正直、svnのメリットは「gitに比べるシンプルな仕組みで、覚えることが少ない」くらいしか無いと思います。シンプルなのはとても良いですが、業務で使うなら別です。
gitを使う理由は「今どきsvnは無いから」ではないです。「gitのほうが便利だから」です。
そして、gitを選んでいるだけで（身分を明かしてないとはいえ）暴言を吐く人が人事担当をしている企業は僕からも願い下げです。（多分、入りたい人は居ないと思う）
よほど大きな理由があって初めてsvnを選択するのが普通だと思いますが、無条件で選ばれるものではないです。 さすがにsvn使いは零細勤務だろうな…
大人数でsvnは無いわ svnというチョイスが40代超えてる
零細企業で高齢社員がsvnマンセーしてイキってる環境って地獄絵図だな
頼まれても入社するやつ居ないだろw >>431
俺なら年俸700超えればギリ納得するかなぁ
でもそういうところに限って逆に給料クソ安いんだよねw >>429
マジレスありがたいが、俺はsvnを推してるわけでもGitをディスってるわけでもないぞ、つーか俺自身はGit使ってるし
>>429のようにちゃんと理由を言えるなら良いがただ古いってだけで「ないわーｗｗｗ」「老害ｗ」とか言ってるバカをディスってるだけ、そういう不勉強なくせに他者に不寛容な奴は将来自分が老害になる 良くも悪くも日本人だよな
ダメなものをダメと言っちゃいけないみたいな風習
svnなんて今どきないに決まってるだろ
そんなどうでも良いところで理由がどうこうとか言うやつの方が面倒くさくて嫌だわ >>430 - 432
心配しなくても大丈夫
SVN使ってるようなとこだと、お前は書類選考で落とされるw .envコミット君とSVN面接官の人は同一人物か？ svnでもgitでもちゃんとバージョン管理を理解して使えてたら良いんじゃね？ツールでマウティングとかクソダサい。ちなみに俺はsvnでブランチ切るとイライラしてしまう体になったので、今後もgitしか使いたくない。 >>426がいきなり、SVNをディスるな！ってイキりだしたのがきっかけと思うけど、それまでは誰もSVNをディスってなかった件
いきなり被害妄想し始めたのは謎 >>438
オレにはお前の日本語読解力のほうが謎だわ 今時svnはないわーって言ってるレスがすぐ上にあるのに Vue 3.xの機能がVue 2.7に降りてくることになりそうなんだけど
LaravelもIE11サポートできなくなりそう このスレで以下の話題は禁止です。
・零細
・Laravel-Mix
・SVN
・.envをコミット
・/vendorをコミット wordpressも次のアップデートでIE切り捨てるわけですし。 >>443
JSONの脆弱性について語っても言いか？ ここの奴らて、Eloquent使ってんのかな？偏見かもしれんがSQLゴリゴリ書いてそうなイメージあるわ。 >>443
勝手に禁止すんなよ
オレは特殊環境の設計/運用の話は聞きたいぞ
荒らしてんのはミジンコだろ？見つけやすいんだし、放置すればいい >>443
node_modulesをコミットが抜けている VSCode1.54.3、Laravel8.27.0 PHP8.0.0 です。
$this->testMethod();
と記述した際、testMethod が定義されていなかったり、typoだったり、引数が足りない・型が異なっている時に
下線などで指摘してほしいんですが、よさげな機能拡張ありませんか。
（inteliphenseいれてますが指摘してくれなくて） >>450
VSCodeは補完が弱いから諦めてPhpStorm使うか、そもそも補完気にするならphpやめて静的型付け言語で開発しな
あとスレチ、Laravel関係ない >>425
元々禁止だったところな話じゃなく
元々は普通にプロジェクトで使われたのが一件で新規に使用禁止になった事案があるんじゃないかって話 >>443
laravel-mix使わないならぶっちゃけsymphonyでもよくね？ってなるんだが何基準でLaravelを選んでるんだ？
フロントをフレームワークでやらないならこんな頻繁なバージョンアップで仕様がコロコロ変わるもの
型遅れのLTSで作ってもサポート期間短いだけだろ >>446
検索以外は完全にEloquent使ってる
検索で複雑なのでもクエリビルダにDB::raw挿せば済むものは可能な限りその範囲で済ませてる
それで無理なのは生クエリに近いのをガリガリ >>453
symfonyはwebpackerがあるな >>455
寧ろ仕様とサポート期間安定面でバックエンド全依存なものをLaravelで作るのは無謀じゃないかって話 postcssとかvueとかはinitするときに選択して自動的に設定おこなってほしいとは思う laravel new blogしたときそういうの出てこない
tailwind使いたいときvue 3を使いたい時など自分が使いたいものを選ぶ機能はない >>459
laravelコマンドのことか
vue-cliとかviteのこと言ってるのかと思った >>454
いいね。前にみたとある現場のコードはノーEloquetで数十行にわたる文字列連結を経てSQLにするっていう、それLaravel使う必要あった？みたいなのだったんだよね。
なので、オレ流みたいなのにこだわりありそうなこのスレの一部は、似たようなことやってそうだなって思ってしまった。 >>453
よくわからんがLTSのサポート期間3年て短いのか？
あとeloquentとかbladeとかFormRequestとか jetstreamとかlivewireとかmailableとかキャッシュサーバー使ってない人なら、
単純なMVCフレームワークで良いわけでsymfonyにしようてのは一定真理だと思う。 >>453
sanctumとかAPI作るときに役立つ機能が豊富なのと、SPAで作ってなかった時の知識がチーム全体にあるからかな >>453
言うほど仕様コロコロ変わるかな？
俺は5.4〜8まで使ってるけど、2021-04-03追加はあるけど破壊的な変更ってあんまない気がするな >>464
「機能」って打つつもりが機能の日付に変換された
× 2021/04/03追加
○ 機能追加 >>465
すみません。また間違えました
×機能の日付
〇昨日の日付 >>464
たぶんL aravel詳しくなくて印象で語ってるだけだと思うぞ。 完全SPAでやってるがLaravelの標準の認証がstatus:204を返すように変わったとか知らんヤツの方が寧ろ多いだろうな 8から入った新人だけど
そこらにありふれてる5〜6の記事を参考にすると動かなかったことがある
モデル関係とか そういえばLaravelってなんでルートの書き方を変えたんだ？
今までの書き方だと何か都合がわるかったのかな？ >>472
あれのメリット分からんのはさすがにエアエンジニアだと思うが
テキストエディタで開発してるならともかくIDE使えば分かるだろ… バージョンの数字に騙されてる人が居るようですね。
そういう人が多くいる為、
「メジャーリリースを6ヶ月単位から1年単位に減らします」と公式ブログで宣言してますよ。
・6.0からセマンティックバージョンを採用したのでバージョンの数字が大きくなった
・リリースサイクルはそれ以前とは変わっていない
・コミュニティにとってはリリースがとても頻繁になったと感じているようだ
・コミュニティに「取り残された」という実態とはズレた感覚を与えてしまっている
僕としては今のところ既存機能への変更点はそんなに多く感じてなくて、
sanctumやpassportなどのように拡張機能が追加されていってるのがメインだと感じています。
https://blog.laravel.com/updates-to-laravels-versioning-policy >>473
Laravelがルートの書き方を変えたのはJetstreamで使うLivewireのためだね
IDEは特に関係ない お前らLaravelに詳しいな
俺なんか客の要件通りに開発して出すのが精一杯で拡張とかぜんぜんわからん gitもSVNも使わんぜ。
WinSCPで本番のファイルを直接編集してこそ漢。 composer.lockやpackage-lock.jsonはバージョン管理にコミットしないのが
正解でいいんだよね？
.envの論争見てよくわからなくなってきた >>479
そもそもロックファイルの役割を理解してる？ 皆さん開発は自分のPCでDocker動かしてる感じですか？
そこそこのスペックのPCでも重くないですか？ストレスなのでVPS上の開発に戻そうかと考え中 重いのか？
俺はWindowsだけど重いと感じたこと無いな
まぁでもコンテナ50個くらい起動すれば重くなるのか？
そんなことしねえけど >>482
3年前に組んだRyzen7 2700X メモリー32GB 1GB NVMeSSDだからまだいけるはず
コンテナは4個ぐらいだな、Laravelのフォルダをマウントしたらかなり重い >>479
composer.lockはコミットしろよバカ
理由はググれks >>479
composer.lockはコミット
package-lock.jsonはコミットしない
この運用でOKだよ >>486
スターバックスで出会って3年前から付き合っている俺の彼女のPCのほうが
俺よりもスペック上だよ だからハイスペPCでもDocker重すぎなんだよ
Xamppに変えるわ WSL2のDockerは遅いらしいよ
ググれば事例と解決法がたくさん出てくる
つかHyper-Vで良いじゃんWSL2使ってないわ >>489
スターバックスで出会って３年付き合ってる情報いりますかねぇ >>478
appとresourcesとroutesだけ定期的に物理コピーでバックアップだな >>485
そんだけメモリあるならVirtualBoxかHyper-VでCentOSとか動かした方がいいんじゃないか？ >>492
WSL2でクッソ遅いからHyper-Vに戻したがやっぱり遅いわ
ぐぐるとなんぼでもワークアラウンド的な解決策は出てくるが根本的な解決策はない Dockerは軽量って触れ込みだったのに、動かしてみるとファイルマウントが罠か
回避するためにVS Codeのリモート拡張入れるとか、もうそれ昔みたいにリモートでやれよ node_modulesとvenderをマウントしてるとめちゃ遅いから、ここをマウントしないようにすると普通に使える
sail？なにそれ？美味しいの？ そこ外してるんだけどなあ
あとタスクマネージャー見てるとたまにメモリ食い尽くしてる時がある、20GBとか
再起動したら直ってしばらく起きないんだけど起きるタイミングが不明 やっぱりnode_modulesやvendorはコミットしないほうがいいのかなぁ すみません、質問なのですが、node_modulesとvendorはコミットしないほうがいいんですか？ インターネット接続できないサーバで運用するなら、リソース一式まるごと管理する意味で、やはりコミットしたほうが良いと思う。 そりゃねーだろ
外に繋がるサーバで雛形プロジェクト構築して
rsyncでまるっと引っ張ってくるとかじゃね？ 個人的にはnode_modulesとvendorはコミットしたほうがいい気がする
.envはもちろんコミットしちゃだめだぞ >>509
.envコミットしてはいけないのは常識だろ・・・ .envはともかく他はコミットすれば良いだろ
なんで無駄に管理システムを分けるんだよ 自宅で42Uラック全部埋まってるLaravel使いの俺がきましたよ すみません、質問なんですが、composer.lockはコミットしないほうが良いんですか？ composer.lockはコミットしなくてもcomposer installってコマンド実行したら
ライブラリダウンロードできるので大丈夫です。
ただしcomposer.jsonはコミットしてください Composer実行できない環境のこと考えてないよな composerを前提とするフレームワークなのにcomposerを使えない環境を考慮するのか LaravelってPHPが使えない環境のこと考えてないよね このクソレスの応酬はいつまで続くんだろうなぁ。
そういえばAPP_DEBUGをtrueにしてた人がignitionの脆弱性つかれてマイニングツール仕込まれたってのをqiitaで報告してた。
このスレAPP_DEBUGをfalseにするという当たり前のことできてない人いそうだから、気をつけろよな。 >>514
ガチで信じる人多そうな悪質なアドバイスだなw laravelってphpエンジニアの大半が馬鹿だってこと考えてないよな そもそもLaravelは職人のためのフレームワークなんだからな。そういうのは相手にしてないよ。 >>522
いやcomposer.jsonがいればcomposer installしてダウンロードできるのは本当だろ vendor以下のバージョンが多少違ったからと言って動かないケースはほとんどないからな >>526
ほとんどない、とか曖昧なことを言い出すのが、ここには零細しかいないことの証明だよな ここで零細零細て言ってるやつらは、逆にいうと大きいとこに勤めてんのかな？俺は従業員数単体で1000人ぐらいの中小。 >>528
中小企業って法的定義があるの知ってる？ 法定義ではサービス業の場合100人以下が中小だろ。でも、オレの周りで1000人で大企業て思ってるやつはおらんのよね。 .envコミット君が荒らしてるのだけはわかってるよ 零細か大手かじゃ曖昧で分からんでしょ
プロジェクトごとの開発チームが何人居るじゃね
大手にいても開発チームが3人しか居ませんじゃ話が噛み合わないだろ >>534
大手の少人数チームと、零細の少人数チームが一緒だと思ってるの？
開発基準とかベースの厳しさがそもそも異なるんだが。 528だけど、開発チームは2人だけ。ただ全社横断の開発部の指針に従うから当然クレデンシャル入りの.envをリモートリポジトリにコミットなんてしない。プライベートリポジトリであってもね。
バージョンもサポート終わってるバージョンいつまでも使うのは許されないから、バージョンアップを計画しないと怒られるね。 web系もピンキリだよな
「webアプリ作ってwebサービス提供してます」
と
「webサイト作ってます、受託でコーポレートサイト作ります」
だと同じweb系でもレベルが全然違う 結局スレの結論をまとめると
.env→コミットするな
node_modules→コミットしろ
vendor→コミットしろ
composer.json→コミットしろ
composer.lock→コミットするな
package.json→コミットしろ
package-lock.json→コミットするな
になるのか？ >>542
package-lock.jsonはコミットしたほうがいい
他はその通りだね >>542
まとめるものでもないし、勝手に総意にするな >>544
.envコミット君こんにちは＾＾
そろそろ.envコミットしてはいけない理由わかったかな？ 【速報】LaravelでCVE-2021-3129という脆弱性が見つかる Laravelのプロジェクト生成でlaravelコマンドを利用する方式と
composerコマンドを利用する方式の2種類がありますが
これってなんで2種類用意されているんですか？
laravelコマンドのほうが便利なオプションが用意されているとか
そういう違いですかね？ >>546
アホか。1/20に報告されてるし、すでに現場のエンジニアなら問題無いって判断下している。速報とか恥ずかしすぎ。 vendorはファイル数が多すぎるからコミットしない みなさんは本番環境でのみ処理が遅くなる現象などに遭遇した場合どうしてます？
プロファイラー有効化してしまえば色々な情報をWEB画面から取得できるから調査がはかどるけど
本番環境でプロファイラー有効化するのはセキュリティ的にあれだし・・・ 質問させてくださいLaravelで作ったアプリを公開する時に
http://homohomo.comでアクセスできるようにするか
http://homohomo.com/homomapでアクセスできるようにするか
二通りあると思うんですけどLaravelってどっちを推奨していますか？ >>554
どっちも推奨してないぞ
自分で好きに決めなよ >>553
プロファイラってなんだ？
stacktraceのことか？
本番環境でもログには出力するだろ… >>554
アクセスしてみましたが見れないようです
まだサービス公開前ですか？ vendorと.envコミットする派の人たち
・零細
・個人事業主
・日曜エンジニア >>560
ちょっとネタっぽく聞こえますが、結構当たってるように見えますね。
このスレ見てると分かります。
僕が働いてる会社だとこのレベルのエンジニアが居ません。
居てもせいぜい新卒1年以内の新人ですかね。 >>561
.envコミット君が荒らしに来るからそこまでにしておけ >>560
1000人以上の会社だが、納品先によってはすべて含めてコミットだ。 あー、零細のようにメンバー少ないとプルリクのレビューしてないってのはあるかも？
その程度のことってレビュー通すとまず確実に指摘されるだろうし リリース担当者も居ないくらいカツカツに切り詰めてるのにレビュアーなんて置けるわけがない でかい企業になるほど、イレギュラーなことしなきゃいけなくなる。
コンプライアンスとガイドラインに縛られまくるの知らないやつは、3年目以下だろｗ コンプラとガイドラインに縛られてるなら、クレデンシャル情報の入った.envをリモートリポジトリにコミットなんてさせないだろ。アホがコンプラやガイドライン作ってるなら有り得るのかもしれんが。
最近GitHubもプライベートリポジトリにクレデンシャル情報入ってたら、警告する機能追加しているぐらいだぞ。 >>568
そもそもそんな環境なら、.envにクレデンシャル情報なんて書かねーよ 前スレから見てて思ってるけど.envがどうこうとかどっちでもよくない？重箱の隅だろ
みんながコンプラがどうとか一生盛り上がってるからジャップランドの生産性低いんだよ >>569
まぁそうなんだが。だからこそ、>>567の言ってることが言い訳にしても酷いって話しね。 DBのユーザー名とパスワード書くのはイレギュラーじゃなくない？デフォルトのテンプレがそうなってるんだし >>571
ん？オレはお前の言ってることのほうが理解できないけど？？？
.envをコミットしてもよいかダメかは展開する環境に差異があるかないかなんで>>568の指摘は的外れ
そもそも、>>567は.envに言及してない。会社がでかいと縛りによってイレギュラー対応が必要になるって言ってるだけだし、一般論として正しい >>570
googleやfacebookのエンジニアがコンプライアンスに縛られてないとホンキで思ってそうｗ 567は>>560や>>564の流れから来てると判断したんだが、違うのか？あとイレギュラーつってもなんでもありな訳じゃないだろ。 そもそもコンプラ以前に環境ごとに異なる値をコミットしても意味ねーし邪魔なだけだろ ventorも.envもコミットするバカの思考が理解できない >>579
初心者なだけだろ
温かい目で見守ってやれ >>579
マニュアルもろくに読まず、モダンなデプロイなども知らず、我流でやってきたんだと思う。それで指摘されると逆ギレして、マニュアルを盲信するバカって言ってくるあたり改善の見込み無し。 マニュアル読まないのはクソだけど盲信するのもよくない
LaravelはマニュアルでDocker Desktopを推奨してるが重くて使えたもんじゃない みなさん教えてください Laravelになれるために
composer create-project laravel/laravel:6.* sampleと実行して
プロジェクトを作成し簡単なTodoアプリを作ってみました
その後自分の別の仮想環境にデプロイしてみようと思いWEBサーバのドキュメントルートに
gitからcloneしたアプリを配置してcomposer install --no-devと実行しvendorにライブラリが
配置されました。
ここまでは良かったのですがDBのセットアップを行うために（練習なのでsqliteです）.envを編集し
php artisan migrateを実行したところCommand "migrate" is not defined.というエラーが
出てきました。
デプロイ時も--no-devオプションは付けてはいけないということでしょうか？ すみません途中で送信してしまいました
--no-devオプションを外してcomposer installを実行したところ
php artisan migrateが動作するようになりました。
laravelをデプロイする際には
１．composer installする
２．migrateコマンドを発行
３．DBのセットアップ完了後はvendorフォルダを空にしてから
composer install --no-devを実行
という流れになるということでしょうか？ >>585
devでしか使わないパッケージをよく分からないままapp.phpのサービスプロバイダに登録し、結果--no-devオプションが途中でこけていただけでは？
--no-devで実行した時に本当にエラーメッセージ無しに完了したか確認したか？ >>585
--no-dev で良いと思いますよ。
まず大きな違いが「本番環境にログインして直接migrateをしない」という点です。
migrationの機能はローカルに構築されたLaravelを使います。
本番環境用のDB設定を用意した .env.prod をローカルのプロジェクトに用意して
php artisan migrate --env=prod です。
これで本番環境に開発者用機能をインストールすることなく、migrationを実行できます。
当然、migrationのファイルは本番にデプロイされたファイルではなく、ローカルに存在するファイルを使います。
git checkout master を忘れずに。
また、質問と関係無いですが、このスレにはなぜか勝手に質問者を騙る人がたまに居るので気をつけましょう。
私のようにIDを出して書き込めば安全です、 >>543
lockファイルのコミットってなんか意味あるの？ 安定稼働してるバージョンで固定したいとかないの？
常に最新にしておきたいタイプ？ >>588
むしろ君がlockファイルの役割を理解してる？ >>590
いいえ、彼は理解していないと思います。ただの僕の推測ですが。
なぜなら、「lockファイルをコミットする意味はあるか」という質問に対する答えは「はい」しか無いからです。
lockファイルに役割がある以上、「いいえ」という答えになることはありません。
役割を理解した上でコミットする必要性があるのかという疑問が出てくるかも知れません。
その場合は先の質問内容ではなく「lockファイルをコミットする必要はあるか」という質問になります。
（この質問に対する答えは、必ずしも「はい」とは決まっていません）
その上で後者の質問に回答するとすれば、僕は必ずコミットします。
なぜなら、例えマイナーバージョンの違いであろうと環境毎に差を出したくないからです。
特定の環境でのみアプリケーションが正しく動作しない場合、ライブラリのバージョンに依存するかもしれないという可能性を残してしまうからです。 俺のLaravel、package-lock.jsonなんてファイルないんだけど… lockふぁいるはコミットしていいんだよ
理由はググれば記事が出てくる
ただしvendorと.envはコミットするなよ >>595
npm installしてないからだろ ライブラリのマイナーバージョンに絶対差を出したくないならvendorもコミットすればいいじゃん >>598
それなw
lockファイルをコミットしてvendorはコミットしないとか矛盾しすぎw 矛盾とは思わんけど
一応どっちでも同じ目的は達成できる
Composerがちゃんと動いていればだけど てか、Laravelプロジェクトに最初に入ってる.gitignoreに従えば良いだけだろ
なぜそれに抗おうとするのかが謎い >>376 によると環境依存あるから
vendor以下はコミットしない方がいいと思うけどな
そのサーバ上でcomposer installするのが確実
もしくはサーバーのクローンからrsyncで転送するとか バカ1「僕のDBパスワードは test123 だ。今の.envと異なるから書き換えてコミットしよう」
バカ2「私のDBパスワードは lara456 です。勝手に.envを変えないでくれませんか？」
バカ3「クレデンシャルを.envに記載するのはコンプラ違反です。そこだけ空欄にしましょう」
俺（じゃあファイルごと除外しなよ…）
バカ4「本番環境のクレデンシャルは履歴管理するべき！」
俺（ごもっとも、でも別の場所で管理してね）
バカ5「マニュアル盲信乙！マニュアル無いと何もできないの？」
俺（君はセオリーを理解した上で我流でやってくれ） もうスレを荒らさないでくれ
.envコミット君とライブラリコミット君は延々と同じことしか話さないし他所でやってくれないか？ >>608
少し落ち着きなよ。カルシウム不足かい？ 自分はviewもblade.phpで書いてしまうけど
みなさんはvue.jsで描画しているんですか？
blade.phpではなくvue.jsで描画するメリットって何かありますか？ >>508
venderはまだしもnode_modulesは無駄がデカすぎだろ
新しい環境にデプロイしてもnpm installすりゃいいだけじゃん あれだけ説明受けて605みたいのがまだいるんだな
自分の環境しか知らないって怖いわ >>508
node_moduleはnpm installで環境に合わせたバイナリ落としてきたりする奴いたりするのでやめといたほうがええで 担当者が変わっても扱えるように開発環境も実行環境もWindowsなんだよね >>613
>>605じゃないけど、どの説明もクレデンシャル情報の入った.envをリモートリポジトリにコミットする理由の説明にはなってなかったよね？逆にどの説明が理由として真っ当だったか教えてほしい。 >>617
> 俺（じゃあファイルごと除外しなよ…）
.envを入れなきゃいけない環境があるって言ってんだろ
必要なら環境変数で上書きしろ
> 俺（ごもっとも、でも別の場所で管理してね）
ごもっともじゃねーよ。.envは環境定義だって言ってんだろ
クレデンシャル情報をどこに持つかはセキュリティポリシーやガイドラインで判断しろ
> 俺（君はセオリーを理解した上で我流でやってくれ）
まずお前がセオリー理解しろ
お前が言う通り、クレデンシャル情報をコミットするかしないかは.envのコミットとは関係なく判断されるべき
お前がなんでよくわからんことを言い出したのかがよくわからん >>618
>>605じゃないって言ってるのに、>>605の話されても困るんだが・・・。あと俺は理由を説明してと言ってるんだ。ケースバイケースとか言って逃げるのはやめて。
ちなみにクレデンシャル情報入れないなら、それこそ.envコミットする理由はゼロだよね。 >>618
ついでに言っておくと環境変数で上書きするぐらいなら、環境変数そのまま使っとけよ。.envに書かないとLaravelは環境変数として扱えないと思ってんのか？
更に言うと環境の定義ではなくて環境ごとの値を定義しているから、dev、stg、prdで全く同じ値を使うことがない限り、.envを使う意味はないって話もしてたよね。
さらにセオリーも.env否定派はLaravelのマニュアルや12Factors引用して話してたと思うんだが、お前の言うセオリーって何？ Laravel以前の初歩的な知識がないやつってなんなの 追加で必須情報(環境変数とか)を設定しないと動かないソースは洗練されてない感じがする リポジトリからチェックアウトしてそのまま動くことが要求されるから
.envもvendorもコミットせざるを得ない
俺じゃなくて蔵が悪い バカ1「僕のDBパスワードは test123 だ。今の.envと異なるから書き換えてコミットしよう」
バカ2「私のDBパスワードは lara456 です。勝手に.envを変えないでくれませんか？」
バカ3「クレデンシャルを.envに記載するのはコンプラ違反です。そこだけ空欄にしましょう」
俺（…）
バカ4「本番環境のクレデンシャルは履歴管理するべき！」
俺（…）
バカ5「マニュアル盲信乙！マニュアル無いと何もできないの？」
俺（…） >>624
その説明ならまぁ理解するんだが、コンプラとか謎の理由つけるやつが居るのがね・・・。そして、そういう現場を知らないのは初心者だからとか訳のわからん理由をこねくり回す。
皆が皆、そんな異常な現場を知ってるわけじゃないし、むしろ複数の現場知ってるような経験者なら、その異常な現場を根拠に.envコミットの正当性を主張するはずもなく・・・。 .envコミットは必要か？
環境変数でオーバーライドするために必要
→環境変数そのまま使え
履歴管理するために必要
→コードの管理と分けろ
本番環境しかないのでその方が楽
→.env使わずconfigに書けば良いだろ
チェックアウトしたらそのまま動く環境ガー
→あ、はい
こんな感じかなー システム作って客に納品する請負開発組と自社WEBサービスの開発やってる奴とで
開発にかかる金の意識も成果物に対する意識も全然違うと思う。
後者は金のこともソースをその後どう扱っていくかもそんなに考えて無いじゃないかな >>630
散々言われてるけど零細かそうでないかのほうが大きい気がする 普通に.envを環境別にコミットして、環境変数でファイル名で指定する運用してるとこもあるのでは？
このスレでもそんな事言ってる人いたし、別のフレームワークでもある運用だし
せっかく環境晒してイレギュラー対応してる実情を教えてくれてる人がいるのに、それをバカとか言っちゃうやつの知的好奇心のなさは理解できねぇ .envコミットするにしてもプロジェクトのリポジトリに同居させるのはどうかなー
コミットするならローカルリポジトリとか別に立ててやるかな >>632
>>241 のやつか
俺は次のプロジェクト前に少し検証してみて、問題なさそうなら採用するかな >>632
>>241の話をしているならちゃんと読め。.envはコミットしてない。環境ごとに別のファイル名で管理してるだろ。 jsonが脆弱だの、.envのコミットがどうだの、よくそんなことで盛り上がれるな、お前ら >>635
それを世の中では「.envをソース管理する」っていうんだぞ .envの使用頻度自体下がってる
コンテナ立ち上げる時に環境変数として渡してあげたほうが楽だしな >>623
APIトークンとかもコードに入れちゃうの？ >>637
お前の中だけの話を世間一般の話にするなよw >>641
釣られるなよ。
それ、知らない環境を一律バカ扱いしたやつに対してのあてつけだぞ。 https://12factor.net/ja/config
アプリケーションがすべての設定をコードの外部に正しく分離できているかどうかの簡単なテストは、認証情報を漏洩させることなく、コードベースを今すぐにでもオープンソースにすることができるかどうかである。 >>638
環境変数で渡してるコンテナ設定ファイルを、githubで管理してるうちの会社。 このスレ見てるとプログラマーという奴らがいかに建設的な議論ができないかよくわかる
仕事ができないオタクばかりなんだから経営陣や営業から馬鹿にされるのは必至だよね >>645
別にそれ自体は悪いことじゃない
前提となるセキュリティポリシーとガイドラインが適切に設計されているかが重要 バカが集まるスレをわざわざ見て○○はバカばかり！とわざわざバカにするバカ >>645
コードと分離して、本当にアクセスすべきやつだけに絞って管理し、git secretで暗号化できてるならアリ。とりあえずこの辺を読んでおくと良い。
https://blog.gitguardian.com/secrets-api-management
和訳
https://itnews.org/news_contents/secrets-api-management
>>646
標準化の意識がなくてオレオレプログラミングにこだわる奴らはアマチュアだと思うから、それを職業プログラマ一般に当てはめるのはどうかと思うぞ。 昨日も.env
今日も.env
明日も.env
これは零細煽りが相当効いたんだろなぁ… .envコミットしている人ってpackage-lock.jsonもコミットしてそうｗ そもそもLaravelerの内のどれぐらいがnode,npmをちゃんと使えてるのかっていう 零細かどうかは知らんけど、マニュアルも読まない我流プログラマが何人かいることだけは把握した。 零細煽りが効くと思ってる人って普段からそんな事ばっかり気にして生きてるんだろうか 流れがよく分からないけど>>629みたいな奴がプログラムとミドルのリポジトリを分けろと騒いでるって事でFA？
どっちでもいい気がするが ミドルって何だろ？ミドルウェア？そんな話してたか？ そんなことより.envをコミットするかどうかについて語らない？ >>559-562
ここで言うミドルはミドルエンバイロメントのことだけど
リテラシー低いね君たち >>659-662
ここで言うミドルはミドルエンバイロメントのことだけど
リテラシー低いね君たち ミドルリポジトリとかミドルエンバイロメントってなんだよ
適当な言葉作ってんじゃねーぞw 勤め先が零細かどうかなんて正直どうでも良い。俺が問題にしているのは、技術力や知識が零細ってこと。
公式マニュアルに書いてあるよって教えてもらったら、感謝してまず読め。読んでもない奴が「マニュアル盲信」とか言うな、カッコ悪い。 >>669
「公式マニュアルに書いてあるよって」どれのこと言ってんの？ マニュアル盲信批判君はマニュアル嫁って奴とマニュアル人間をゴッチャにしてバカにしてんのかな >>669
これのことかな？
https://laravel.com/docs/8.x/configuration#environment-file-security
でも、その少し前にLaravelではDotEnvを使ってるよって書いてあるんだわ。
で、みんなはそっちまで見てコメントしてる。もっというと、その先の「twelve-factor app」まで見てる。
それを見ると、機密情報の取り扱いに関して双方のドキュメントで矛盾が出るんだけど、実践面から「セキュリティポリシーやガイドライン」で判断するといいよ、ってアドバイスしてくれてる人がいるのよ。この辺を理解しないと「マニュアル盲信したままだとまずい」ってことだね。
ここまでが今までのスレの流れなんで、教えてあげたんだから君は僕に感謝してくれてもいいよ。 >>672
>>175で12factorsのリンク貼ったのは俺なんだけどな。レベルの低い議論してたから。
んで、そのあとlaravel公式の話になって、.envコミットするアホが多いから明示されるようになったのかもみたいな話をしているところに颯爽と現れたのが、>>247や>>266みたいなアホ。 >>672
あ、お前は俺の貼った12factorを引用しているみたいだが、俺への感謝は不要だから。知らないやつに教えるのは当然のことだと思ってるから。それでも感謝したいなら好きにしてくれ。 「twelve-factor app」知ってて、マニュアルとの矛盾を理解しないってすごいな >>675
頭悪いなお前。>>669は何も知らない奴が我流でやるなって話。マニュアルやベストプラクティスを知ったうえでそれを基準にやり方を現場の環境に合わせろってこと。
マニュアルもベストプラクティス知らないただ無知な奴が編み出したやり方なんて、大抵の場合ただのゴミ。
それを理解しない我流プログラマが居るみたいだから>>669みたいなこと言ってんの。 >>676
老害、顔が真っ赤だな。
勝手にマニュアルやベストプラクティス知らないって決めつけるなよ。
事実としてマニュアル同士に矛盾があって、どちらかというと「DotEnv」側がベストプラクティスよりなんだから「マニュアル盲信すんな」が正しいだろ。
頭悪すぎ。 >>658
ところでミドルって何？ふざけずに答えてくれない？ >>678
これな
自分と違うやり方、マニュアル通りじゃないやり方に対して「マニュアル読まないバカ」「自分より知識の劣ったバカ」と決め付けて煽る行為はイカンよね
>>676がそうだったかはわからないけど >>678日本語理解できないのかお前は。
しかもdotenvも12factorの思想に基づいていて、.envはアプリのコードと分離しろってREADMEに書いてあるんだが。.envをコミットさせないlaravelの公式マニュアルとも矛盾は無い。
お前自身dotenvも12factorsもlaravelのマニュアルも読んだことがない雑魚プログラマてことだよね。あーそれで俺に突っかかってくんのか。 せっかく手に入れた技術で金を稼いだり他人を幸せにするのでなく他人を煽ってからかうために使うなんてしょうもない人生送ってますね いや、.envをコミットするものだよ
いちいち「.envはコミットしちゃいけない！除外しろ！マニュアルが絶対！」って言ってるのは零細社畜の証拠 >>684
それな、大手はみんな.envをリポジトリに入れてる >>682
あれ？マニュアルぐらい読んでるわ！て言い返して欲しかったなぁ。もしかして図星だったか？まぁどうでも良いけど。 マニュアル読まずにトンチンカンなことを言うのもカッコ悪いし
マニュアル読んだぐらいでイキるのもカッコ悪い
こんなスレに生息する時点で全員底辺なのを自覚すべし、わかった上で荒らして遊んでる奴もいるがもちろんそういう人生もしょうもない マニュアル盲信するなって、クレデンシャル情報の取り扱いに関してだろ
老害な人、日本語大丈夫か？ >>688
イキってるわけじゃないぞ。マニュアルやベストプラクティスを前提にするのはただの基本の話なのだから。基本ができてるだけでイキれるわけないじゃん。それやって初めてスタートラインなんだから。
つーか、ここでそれやってないやつって俺に絡んでるやつぐらいでしょ。皆当たり前のようにやってることだぞ。だからこそ.env否定派からはマニュアルのリンクとかがすぐ出てくるんだろう。 機密情報をGitに上げるなって事？
マスクして保存すりゃいいじゃん
馬鹿か ちゃんと.envに設定可能な値として入れてくれてるならまだ良い
機密情報に限らず、
あちこちで環境依存の値をハードコートしてて
後で運用の仕方が変わった時にそれを変えて回るのはめっちゃ大変 機密情報云々じゃなく、環境依存情報だろ
プロジェクトのリポジトリにコミットする意味が分からん >>692
逆転の発想で
DBのパスワードが下の方のクラスに直書きされていて知らないとどこにあるかわからないとか、隠したいなら逆にそうしたほうがええかも すみません、質問なのですが、結局.envはコミットしたほうが良いのですか？
スレを読んでみたのですが、意見が二分していてよく分かりませんでした。
初心者なので自分で判断できません。 >>700
勝手に終わりにするなよ。質問には答えていこうぜ。 バージョン管理下の.envと
バージョン管理外のローカル.envをマージして使えたらさいつよ >>699
判断できないなら、大人しくマニュアルやベストプラクティスに従っておけば良い。つまり.envをコミットしてはいけない。 >>699
結論を言うとプライベートリポジトリなら.envを登録しても問題ない
公開リポジトリしか使えない貧乏人が事故らないように公式は登録するなって言ってるの おいおい、無料アカウントでもプライベートリポジトリ作れるって知らないエアプが湧いてきたぞ。どうすんのこれ？ >>699
何のために.gitignoreに.envが除外しているのか考えろバカ >>707
マジで？俺のgithubリポジトリ作成時にプライベートリポジトリがdisableになっていて
選択不可なんだけどどうすれば使えるの？ なんか別アカだとプライベートリポジトリ作れた
どういうことだこれ？ お前のリポジトリの設定がどうなってるか知らないし、ここLaravelのスレだから質問するだけ無駄だと思うぞ。 GitHubで非公開リポジトリが無料で作れるようになったの最近だろ
昔は作れなかった なお、bitbucketやGitLabはずっと前から無料アカウントでプライベートリポジトリを作れていたので、>>706はgithub無料化の話を知らなかった上に、gitリポジトリを扱うサービスをgithub以外に知らなかったことになる。 >>720
Laravelの公式に教えてやれば？
.envについての話は無料化の前だろ みなさんありがとうございます。
つまり、リポジトリを非公開にすると環境ごとに.envを変えないから大丈夫ってことなんでしょうか？
友達4、5人くらいでウェブアプリを作ってるんですがDBのパスワードとか秘密鍵をみんなで共有するのイケてないなーって思ってたところでした
githubが1年前に対応してくれてるから、もう大丈夫ってことなんですよね？ >>725
イケてないなって自分で思ってるのにわざわざリポジトリに入れてるのが謎すぎる >>725
騙されたらダメだぞ。
ベストプラクティスとして知られる12factorsではリポジトリが明日OSSとして公開しても問題無いか？を判断軸とせよとしている。つまり、プライベートであろうがクレデンシャル情報を入れるのは良くないということだ。
https://12factor.net/config
また、>>649のリンク先では、gitリポジトリの特性上プライベートリポジトリといえども、クレデンシャルを入れておくのはリスクが大きすぎるとしている。やるなら、コードとリポジトリレベルで分割し暗号化した上で保存せよと言ってるね。
さらに、Laravelの5.2以降のマニュアルではセキュリティリスクの観点からも.envをコミットすることはおすすめしないと勧告している。
以上の情報をもとに後は好きに判断したら良いよ。 DBのパスワードなんて最悪漏れても、どうせlocalhostからしか繋がらないだろ > リポジトリが明日OSSとして公開しても問題無いか？
例えがありえなさすぎて特殊すぎてピンと来ないな、うまく想像できない
問題があると言えばあるしないと言えばないかも知れないぐらいしかわからない IT系では物凄いニュースになってたからgithubプライベートリポジトリ無料化知らないとかおかしいぞ。
IT系のニュース一切見ない自分でも当日か翌日か、すぐに情報得たし。 初心者でよく理解していないのに、なぜマニュアルやセオリーではなく便所の落書きに意見を求めてしまうのか >>734
なんかものすごいニュースになってたとか言ってるけど正直そんな騒がれていない お前らgithubもよくわかってないのかよ
だからlaravelのjsonの脆弱性のissueも見つけられなかったんだな >>740
いや本当だから なんでプライベートリポジトリ無料化を信じてくれないのか >>741
jsonのissueの話してるんじゃない？そっちじゃないでしょ これで.envコミットするのがどんなやつかハッキリして良かったじゃん。 >>733
>リポジトリが明日OSSとして公開しても問題無いか？
要するに不慮の漏洩のリスクだね
メンバーのアカウントが漏洩したり、githubの不具合で公開されてしまう可能性のこと
そのために環境設定とコードは別々に管理しろっていうのが12factersのご意見だよ >>738
改定は去年の4月だからコロナのリモート対策のためだろうね
あの頃は慌ただしかったから記憶にないな
開発者の大部分は会社勤めで有償リポジトリを使ってるから関心なかっただろうし >>746
わざわざリンクを貼ってあるのに、読みもせず適当な考察するのは恥ずかしいことだね。あとお前会社勤めエアプでしょ。githubの組織アカウントのこと知らないみたいだし。 >>745
そうなんだけど、ソースコードが漏れた時点でそもそもアウトと考えられるから
そこにDBのパスワードが載ってても大した違いはないと思えるんだよなぁ
外から接続なんてできないだろうし
少なくとも俺は仕事で書いたコードで、外部に漏れてもノーダメージなコードなんてないぞ >>748
そこはリスクマネジメント
リスクのレベルに応じて管理の仕方を分ける場合がある
ソースが漏れてもせいぜい流用されるだけで自分のサーバは無事だろ？
でも環境設定が漏れたらハッキングやクラッキングで
直ちに甚大な被害が出る可能性があるから
.envだけ厳重に管理した方が合理的ではあるのよ そら.envに金庫の番号やらオナニーの回数やら書かれてたら大問題になるけど
うちの場合はローカルでしか繋がらんDBやRedisの情報書いてるだけだから
ソース流出の方がダメージは大きいなぁ、これってうちだけ特殊なわけでもないと思うんだが .envにs3やらメールサーバーやらSNS認証用のトークンやらを書くほうが普通だからな。localhostだけで完結している場合はエッジケースとして無視しているんじゃね？ >>753
それは別の話だね
会議でそういう話し方をすると排除されるよ >>753
マニュアル猛信者乙
うちではどの環境でも値を統一してるし、そんなプロジェクトがいくらでもあること分かってる？ >>756
>>753じゃないけど、そんな底辺現場を自慢して悲しくならないか？さすがにそれを正常だとは思ってないと信じているぞ。
あと、猛信て面白いねwww .○envコミット派の生態
- マニュアルは読まない
- ベストプラクティスに興味ない
- 自分のやり方が正しいと思い込む
- github無償アカウントでプライベートリポジトリ作れない
- 底辺現場を自慢する
- おかしいと突っ込まれると客のせいにする
- マニュアル読むやつは猛信者という謎のレッテルを貼る
- マニュアル読めって言うやつを老害認定する
これぐらいか？ あとbitbucketやGitLabを知らないとか、俺が知らないのは大したニュースになってないから！と言い訳するってのもあるか。 >>752
結局それをgitに保存するかどうかだね
クレデンシャル情報は専用のリポジトリに保管してメンバーを限定するのが大企業では一般的じゃないかな
個人情報を扱わないシステムならソースと同じリポジトリでもほぼ問題なし 零細企業では.envをコミットするのが正しい
中小大手は.envを除外するのが正しい
ってことで良いか？ 他言語から来たLaravel初心者ですよろしくお願いします
マニュアル見始めたけど見慣れない用語がよくわからない
大雑把に言うと
サービスコンテナ→インスタンス使う
ファサード→static呼び出し
て理解で大体合ってる？ >>763
まぁ確かにうちは大企業だからってのはあるけど、取引先の中小だって言わなくてもそれぐらいのことはやってたけどなぁ。
だから、ここ見てると俺の知らない魔境みたいな現場がスゲー沢山あるんだなって勉強になる。 >>763
うち、それらの情報はクライアントからメールで受け取ってそのままだわ
もらった値を鯖でvi開いて.envに書くだけ
誰も管理してない >>766
サービスコンテナはクラスをインスタンス化する為の機能のこと
ファサードはその通り >>766
サービスコンテナの理解がかなり雑。それ単なるクラスの説明でも同じにならない？
ザックリお手軽にDIするための仕組みって覚えておくと良いぞ。コンストラクタインジェクション、メソッドインジェクションするときにお世話になる。
ファサードはstatic呼び出しというよりグローバルなヘルパーだと思った方が良い気がする。 環境ごとの設定をgit管理から除外することって、最近の流行りやトレンドじゃないし、単にそれが合理的だからそうしてるだけでしょw
なんで老害と結びつけたがるんだろw >>771
それ以外に言い返す言葉が思い浮かばないんでしょ。そっとしておいてあげて。 >>771
個々の事情を考慮せずに押し付けるやり方が老人臭いんだよ はい、だから僕は以前に言いました。
自分のプロジェクトでは外すのが当然ですが、あなたのプロジェクトでは好きにしなさいと。
315 nobodyさん sage 2021/04/01(木) 19:35:05.19 ID:???
>>314
ね、頑なに.envを外したがる奴って意識高すぎだろw
細かいこと気にしすぎだし絶対童貞だろw
318 nobodyさん 2021/04/01(木) 20:45:22.22 ID:9RqbMYkF
>>315
結論は>>308-310あたりでもう出てると思っていて、それをわざわざ掘り起こして人格否定煽りはみっともないと思います。
頑なに「頑なに.envを外したがる」というのが間違いで、
このスレを読んでいる限り、外す人は
「私のプロジェクトでは外しますが、あなたのプロジェクトなら好きにしてください。おすすめしませんけど。」
というスタンスの方が多いと思います。（僕含めて） 「押し付ける老害」「細かいことを気にする童貞」
煽ってるのはどちらでしょうか。
そろそろ会心しましょう。 そろそろスルーでいいんでない
さすがにみんな飽きたっしょ つうかこれって荒らしによるプロレスだよな？
誰も本気で.envを(ﾋﾟｰ)だなんて思ってないだろw >>767
エンジニアを抱えてない企業もザラだからな
修正やリリースは必要な時に別のSierに依頼することもある
機密だけリポジトリを分けるとかの合理性はあくまで保守担当にとっての話で、オーナーにとってはただの無駄手間と言う事もある >>773
安心しろ。底辺な職場ではそういう異常なのもあるんだなって理解しただけで、お前に押し付けようなんて誰も思ってないから。第一、末端のプログラマにそんな権限無いだろ？ .envを.gitignoreに入れたテイラーオットウェルは真の老害？ パートナー社員に本番環境で使ってるSaaSのAPIキー渡すとかリスク高杉よね >>784
ケースバイケースってあと何回言われたら理解できる？ 渡されるというかこちらが生成からしてるからな
蔵にはそういうのできる奴が誰もおらん、もちろん管理もしてないだろうけど知らん
AWSもアカウント取るところからやらされるからルートのパスワードが実質こっち管理、何かあっても責任取らんとは言っているが 前スレは1000行くのにかなり時間かかったが、
今スレはあっという間なんだが
ええことですやんw >>785
いや渡すだろ もちろん全権限与えたAPIキーではなく
適切な権限を付与したAPIキーを渡すけど >>790
うちの蔵にもそうしてもらいたいわ
多重請けの末端の一人親方の俺しか大企業のAWSのルートパスワード知らんとか恐ろしすぎる コミットしない老害 vs コミットする零細
争いは永遠に続く >>792
あなたが居なくなったら大変だねそのシステム ansibleで配るときに環境毎に切り替えるんだが叩かれるんかな🤔 スレの相違をまとめると、laravel使いは馬鹿が多いってことだね >>798
おまえは馬鹿だがLaravel使いは馬鹿とは限らないな >>798
.envや/vendorを(ﾋﾟｰ)と思ってる人は総じて(ﾋﾟｰ)なのは合ってる >>798
それ程簡単になってるのが良い面であり悪い面でもあるのかな
大抵のプロジェクトは素人みたいなのがやってるからなぁ .envや/vendorを除外すべきと思ってる人は総じて老害なのは合ってる 合理的なことをしたら老害と言われるのは納得いかないのだが
QR決済よりフェリカの方が便利なのにおサイフケータイ使ってると老害と言われるのもおかしい .envをコミットしたいのでSymfonyに乗り換えました！！ マニュアルやベストプラクティスを参照して手堅く開発しようとすると、オレオレ実装している奴らから老害言われるのか。
俺からしたらマニュアル読まずに、配列をarray()で表現したり、分割代入をlist()で受け取ったり、型宣言使わなかったり、Eloquent使わないで生SQL書いてるやつのほうが老害だと思うんだよなぁ。 ぼく「PSR-12を守ってコーディングしてください」
バカ「は？そんなん俺の自由だろ。テメー老害か？」
解せぬ。 ほとんどが対立荒らしだろ
本当は大して興味ないのにわざわざスレを荒らしたいだけ >>808
適合しないケースにまで自分の思想を押し付けるからだよ
ベスプラが老害なんじゃないから間違えるなよ？
おまえが老害なだけだからな >>808
違うだろ
なんで自分の非を認めずに延々と相手に転嫁するんだ？
いい加減自分の押し付けがましさに気づけ いやいや、俺含め.envコミット否定派は肯定派を異常って言ってるだけで、やりたきゃ好きにやれって言ってるぞ。被害妄想過ぎるわ。 >>814
異常呼ばわりまでして押し付けるのか
終わってんな老害 >>814
否定してるのおまえだけだぞ老害
おまえ以外はケースバイケースって結論だ
しつこく押し付けて相手まで中傷したのはお前だけ symfonyでは.envがgitの管理対象になっているのはあれ何でなんだ？ Laravelは老害向け
Symfonyは零細向け >>816
ケースバイケースって言い方してるけど、それって結局マニュアルやベストプラクティスからは外れざるを得ない異常なケースてだけだよ。外れ値ってわかる？
異常なケースをれいにあげて、俺は正常だ！て言われても困るわwww 例えば>>756とかさ、マジで環境ごとに値が統一されてるなら、config内のenv()の第二引数に全部書いたら済む話じゃん？.envに書く必要ある？ >>819
ほら異常呼ばわり
自分が異常扱いされるからネットで仕返しのつもりかな？
寂しい老後だね >>821
じゃあ>>820の質問に答えてみてくれ。 >>821
手法の話してたのになんで人格の話にすり替えようとしてるんだ？ >>822
黙れ黙れ黙れ黙れ もうNT登録したから反論するなよ 普通はさ、マニュアル読んでconfigの仕組み理解してdotenvの用途も理解しているならさ、環境に差異がなければ、環境の差異に対応するために用意されたdotenvの仕組みは不要て判断するんだよね？わかるか？ >>756て、俺からするとその辺を全く理解してないバカってことなんだけど、それに気づかずドヤってて本当に哀れなんだよね。 つかこれって荒らしによるプロレスだよね
誰も本気で.envを(ﾋﾟｰ)だなんて思ってないよな？ >>775
インジョクションって言やいいのになんでイチイチ用語を訳すのかホントセンスないよねアレ .envコミットくん、ようやく自分の環境が異常だって気づいたみたいだな。良かった良かった。 明日は会議があるので寝ます。
今日もenvをコミットしていいのかわかりませんでした。 5chの情報を信じる奴はバカ
つまり5chで質問する奴もバカ
自分で考えろ 結局スレの結論としては
環境に差異がない→.envをコミットしても問題ない
環境に差異がある→.envコミットしてはいけない
ということだよね >>832
環境に差異がないなら、.envを使う理由が無いて話を>>825でしてるわけで。まぁ、それでも使いたい奴は好きにしろってことではある。 まとめてみた
・.envは環境を定義するためのものなので環境ごとに異なる。各環境に直置きし、ソース管理に含めないのがお手軽
・定義すべき内容（テンプレート）は.env.exampleで共有すると良い（こちらはソース管理に含む）
とはいっても.envを管理対象に含めたいプロジェクトはそこそこある
以下の対応をすると良い
＊機密情報の取り扱いに関して
厳密には、.envを管理する/しないとｂﾍ関係がないが＝A以下のように瑞ｮ理すると良い
・どのような立場の人から情報を守りたいのかを定義し（セキュリティポリシー）、その対応としての実装を行う（ガイドライン）
・公式ドキュメントには、「source control repository」からの流出が一例として載っているが、その想定は一般的ではないのでポリシー設計時には自システムに対応した脅威を整理すること
・ルールで縛られることも多い。例えば「データベースへの接続情報は、ミドルウェアの管理者が管理する事」とか「特定管理者以外に資格情報は開示しない」とか
・実装方法は、.envに記述する/環境変数を使用する/変数として管理しデプロイ時に上書き等々あるが、ポリシーとセットで語られるべき内容なので省略
＊.envファイルの管理方法
以下のような実装方法がある模様
・環境ごとのファイルを用意して、環境変数APP_ENVで切り替える（注：defining a server-level APP_ENV）
・各環境のローカルリポジトリとして管理
・共通の.envを用意して部分的に環境変数で上書き
・共通の.envが使用できるように、デプロイ先の環境をそろえる >>836
まとめてくれてるのはいいんだけど、過去ログ見ればわかるから。
結局、laravelの脆弱性対策はどうなの？ >>836
一般的で無いとする根拠は？
- 12factors
- gitguardian
あたりの記事でも、プライベートリポジトリであってもクレデンシャル情報を原則入れるな、だよ。
例外として、以下の条件を満たしている場合はOKとしている。
- アプリのコードと分離したリポジトリである
- 暗号化している >>838
「プライベートリポジトリであってもクレデンシャル情報を原則入れるな」=「流出を危惧」ではないよ
「データベースへの接続情報は、ミドルウェアの管理者が管理する事」とか「特定管理者以外に資格情報は開示しない」って、ルールの背景を考えるとわかる
ソース流出を想定するっていうのは、大雑把すぎるんだ
流出のみでなく、内部統制であったりカジュアルな盗み見防止であったり、理由はいろいろだけど「閲覧できる範囲をより限定的にする」ことがベストプラクティスなのは間違いない
問題は、現状、「閲覧できる範囲をより限定的にする」=「ソース管理からはずす」ではないプロジェクトが多数出てきている事
主にインフラの多様化が進んだせいだね
なので、まとめは「ソース流出」を一般的な脅威と捉えず、ちゃんと自環境の脅威を整理しようね。ってことだろ
この辺は.envを管理対象にするとかしないとかとは本来は関係ない話
どっちであっても、考えなければならない事
セキュアな環境をどうやって作るかってところだね gitguardianの記事を読んでないんだろうか？
そこでは、悪意のある攻撃者はプライベートリポジトリにヤバい情報を置いていると考えて優先度の高い攻撃対象に選定するので、原則置くなって話なんだけどな。せめて置くなら暗号化せよ、だね。
わざわざ「プライベートレポジトリは、シークレットを保管するための安全な保管場所だと勘違いしている人はたくさんいます。」て書いてくれているわけだし。
「勘違いしている人が沢山いる」からそれが一般的だ！て主張なら同意するけど、一般的だから問題無いという主張なら同意できないかな。 >>839みたいな具体的な脆弱性の内容とその対応がようやく出てきてよかった。
どういった状況で何の情報を誰から守るか具体的な対応が取れてるなら他人にとやかく言われることじゃ無い。
「.envをコミットしない」だけじゃ具体的な危険性の説明が無くて大雑把すぎる。
他人に時間取ってもらって対策してもらうには話の進め方が雑 長々と脆弱性の問題書いてるけどさ、それ以前の問題なんだよ、たしかにそれもあるんだけど。
環境ごとに変わる値をコミットしても意味ないし邪魔なんだよ。 発想が真逆で笑える。
.envは.gitignoreでデフォルトコミット対象外なのに、あえてコミットする奴らが居て話題なっている。
そして、そいつらに理由を聞いてもまともな理由が返ってこないというのが現状な。
>>756みたいな恥ずかしい勘違い以外だと客の希望によって仕方なくって話ぐらいじゃないか？ >>844
でかいとこだと一定数存在しそうなルールだと思うよ
過去になんかやらかしてたら、ガイドラインに取り込まれてそうな香りがプンプンする箇所だしｗ
「本番に上げる一時ファイル以外のコードは、すべて管理対象とすること」とか普通にありそう >>841
「ソースコード流出」の例は、粒度がおかしいって指摘だろ
ソースコード流出を考えなきゃいけないようなプロジェクトだと、それ以前に閲覧権限の制限で「機密情報はどうやって管理されるべきか？」って話になるし、流出を考えなくて良いプロジェクトならどーでもいい切り口
ソースコード流出の原因を適当に並べると
・公開範囲の設定ミス
・閲覧可能アカウントの乗っ取り/クラック
・SaaSの脆弱性をつかれる
とかだと思うけど、こんなレベルにブレイクダウンして、コード管理手法を問うようなた議論はこのスレで見たことない(＆スレチ) 本番用.envの設定ミスで本番データがテスト環境のDBに書き込まれてたとか普通にありそう
そういうやらかしやった企業だとよくわかっていない上司が
「すべて管理対象に含めろ！！」とか言ってそうだねｗ .envとしては正しいけどキャッシュのせいで違う値で動作していたってパターンもあるなｗ 話変わって申し訳ないけどlaravel-mixって使わないほうがいいの？
前にこのスレでlaravel-mix馬鹿にしている人がかなりいたけど使うとダメなのかな 別に使ってもいいよ
どうせならvue.jsのスタンダード覚えた方が潰しが効くし、完全にフロントとLaravelを分離できるから、バックエンドだけ移植とかにも対応しやすくていいとは思うけど >>850
使っても良いと思う。大きな問題もないし。
でも使う意味はあんまり無いと思う。
vue-cliを捨ててまでlaravel-mixを使うメリットが無いのと、今なら爆速の開発サーバーviteもあるし、ますます使う意味が無くっなった。 React使ってるからLaravel-Mixで問題ない .envや/vendorをコミットする衝撃に比べるとlaravel-mixを使うなんてどうでもいい
ベストではないがバッドというほどのことではないね >>850
laravel-mix馬鹿にしてたのはたぶん1人。同じやつが何度も書いてたと思われる。 .envコミットは論外だけどvendorやnode_modulesをコミットはケースバイケースだね 逆だぞ
.envをコミットするのはケースバイケース
node_modulesやvendorはOSによってダウンロードするライブラリが違うから
基本コミットしないほうがいい コミットについてにぎわってるようだから自分も質問させていただきます。
laravelのcacheフォルダのファイルってコミットしたほうがいいんですかね？
デフォルトだとcacheフォルダは管理対象外っぽいですけどコミットした時のメリットって何かありますか？
あとlaravel-mixを使用したときにビルドされたcssやjsは管理対象に含めたほうがいいんですか？
それとも管理対象に含めるのはやめて本番環境で毎回ビルドかけたほうがいいんですか？ キャッシュをコミットして本番アップしないと、初回アクセスしたユーザーの処理が遅くなるだろ
大企業ではキャッシュも本番アップするのが常識だぞ >>860
キャッシュは必ずコミットするべき
理由は詳しくは言えんがlaravelのissueを見てくれ、散々.gitignoreから外したほうが良いって言われてる
え、.env？あれをコミットするのはどうかしてるね >>859
お前しつこいぞ。ケースバイケースっていうが>>756のケースしか上がってきていないし、そのケースで.env使うのはアホって結論出てる。
あとOSによってダウンロードするライブラリが違うってどういうこと？お前はwindowsとmacとlinuxでjsやPHPのコードの使い分けてると思ってんの？マジ？
そんな程度だからケースバイケースなんて寝ぼけたこと言っちゃうんだぞ。1年ぐらいROMしとけ。 確かcomposerかnpmでmac環境でしか落ちてこないライブラリとかなかったけ？
最近dockerした使わんから勘違いかもしれんが お前ら初心者を騙すのはほどほどにしとけよ
信じるやつが出てきかねんぞ キャッシュはコミットしない
js cssとかのビルドアーティファクトは状況による
ただリポジトリに入れるとコンフリクトが多くて面倒
小規模なら本番でビルドするのもありだけど、大半は自動ビルドツールを使う >>863
node_modulesがOSごとに違うのは有名な話だろ >>863
なんで老害って他のやり方を一切認めないの？ >>873
認めて欲しいなら>>820の質問に答えような。 どんどんネタに走っていくな
キャッシュのコミットはさすがにネタとしてもやりすぎw
>>860は狙いすぎ キャッシュはコミットしないほうがいいよって言うと
「なんで老害って他のやり方を一切認めないの？」
と返されるのかな OSごとに異なるって、LinuxとWindowsだったらあるかも知れんけど
CentOSとAmazon Linuxぐらいの違いでも変わるの？ 「コンプラがー」「OSの違いがー」
お前ら根本的にずれてるよね
そんなの焦点ですらないのに laravelも最近symfonyに押されつつあるな お前らってデプロイ時のDBの初期データってどうしてる？
本番リリース用のシーだー作ってそいつで登録？
それとも普通にリリース用sqlファイル用意してそいつで登録している？ adminユーザー1個だけtinkerで登録して
後は蔵に全部入れさせる やっと念願のlaravelでアプリ開発できる
よろしく 本番用シーダーは基本作らないほうがいいぞ
あれはあくまでもテストデータを用意するためのツールであって本番環境で使うことを想定されていない
本番用データを登録するならシーダーではなくmake:commandで専用の登録コマンドを作ったほうがいい いやマスター用のseederは環境問わず使うんだから用意するだろ
トラン用のseederはその通りだが シーダーなんてテスト用のゴミデータ入れるためのもんだろｗ
PHP配列書いてデータ管理するつもりなのかｗ Laravelの1+N問題ってのは理解できたんだけど
10+2N問題ってのが全く理解できない どうすればそんなことになるのかもよくわからん .envコミット君といい本番用seeder君といいこのスレは愉快な仲間たちでいっぱいだな >>893
想定はしているぞ。ただし推奨はしていないので、app.envにproductionて文字列が定義されていた場合は、本当にシーダー使う？てプロンプトが出てくる。
https://laravel.com/docs/8.x/seeding#forcing-seeding-production >>896
なんで老害って他のやり方を一切認めないの？ お前らマスターテーブルとトランザクションテーブルの違いも理解してねえのか
マスターテーブルのseederは用意するだろアホか 単発IDで老害って書いてるお前の方が頭が固い老害
老害は出ていけ 俺はいわゆるマスターテーブルみたいなのはenumクラスで定義するから、最近はマスターテーブル自体作らないな。
ただシーダー使ってマスターテーブル作りたい奴は好きにしたら良いとは思う。都道府県マスターとか？ マスタデータをValueObjectのようなクラスで持たずにDBで持つ場合は、SQLを用いた検索をできるメリットがある。
逆にそれがメリットにならないようなデータはDBで持たずにValueObjectで持ったほうがいい。
.envのコミット（多分ネタだと思うけど）と違ってこっちは本当にケースバイケースだからな。 seederなんてテスト目的でも書きたくないわ
php直書きだぞ？メンテナンス性悪すぎだろ >>897
それLaravelじゃなくSQLの話じゃね？ >>906
典型的老害で草
ちゃんと少数派のことも認めろ 俺「ああ…すごく気持ちいいよ、富美男」
富美男が俺のものを、そのごわごわとした手で優しく包み込む。
程良い締め付けと心地良い温もりで、思わず口元が緩んでしまう。
梅沢富美男「バカ野郎が……こういうのはどうだ？チロチロ…」
俺「うぁ…くっ…！！」
富美男が悪戯に亀頭の先端をチロチロと弄ぶ。屈強そうな外見には似つかわしくない、丁寧で繊細な舌使い。
あまりの気持ち良さに、射精感がぐぐぐっと高まるのを感じる。
梅沢富美男「…可愛い顔しやがるじゃあねえかこの野郎…そろそろ仕上げだ。ジュルジュル…ゴプッ！グポポ…ジュルジュルルル！グッポ！ブブブ…！」
俺「ひぁああ…！富美男！富美男ぉお！ぐっ…！！」
富美男が俺の股下で激しく上下する。俺のものはてらてらと光沢を帯び、上下運動を繰り返す度に富美男の唾液と俺の精液が混じり合った、ひどく性的な粘液が滴り落ちる。
限界までいきり立った俺のものは、欲望の全てを富美男の口内に解き放つ。
俺「ああはあっ…！！はあっ！はあ…はあっはあ……！富美男…富美男良かったよ…」
梅沢富美男「…ゴクンッ！……はあっはあっ…てめぇこの野郎！こんなにも一杯出しやがってバカ野郎…腹ん中パンパンじゃねえか…！！…まだ出したりねえよな？」
俺「…富美男には全てお見通しか。敵わないよ、お前には…」
梅沢富美男「当然だバカ野郎…ここからが本当の夢芝居だ」
俺と富美男は、夜が明けるまで、何度もなんどもお互いを求め合った。 >>912
ありがとうございます。保存させていただきました。 俺「ああ…すごく気持ちいいよ、富美男」
富美男が俺のものを、そのごわごわとした手で優しく包み込む。
程良い締め付けと心地良い温もりで、思わず口元が緩んでしまう。
梅沢富美男「バカ野郎が……こういうのはどうだ？チロチロ…」
俺「うぁ…くっ…！！」
富美男が悪戯に亀頭の先端をチロチロと弄ぶ。屈強そうな外見には似つかわしくない、丁寧で繊細な舌使い。
あまりの気持ち良さに、射精感がぐぐぐっと高まるのを感じる。
梅沢富美男「…可愛い顔しやがるじゃあねえかこの野郎…そろそろ仕上げだ。ジュルジュル…ゴプッ！グポポ…ジュルジュルルル！グッポ！ブブブ…！」
俺「ひぁああ…！富美男！富美男ぉお！ぐっ…！！」
富美男が俺の股下で激しく上下する。俺のものはてらてらと光沢を帯び、上下運動を繰り返す度に富美男の唾液と俺の精液が混じり合った、ひどく性的な粘液が滴り落ちる。
限界までいきり立った俺のものは、欲望の全てを富美男の口内に解き放つ。
俺「ああはあっ…！！はあっ！はあ…はあっはあ……！富美男…富美男良かったよ…」
梅沢富美男「…ゴクンッ！……はあっはあっ…てめぇこの野郎！こんなにも一杯出しやがってバカ野郎…腹ん中パンパンじゃねえか…！！…まだ出したりねえよな？」
俺「…富美男には全てお見通しか。敵わないよ、お前には…」
梅沢富美男「当然だバカ野郎…ここからが本当の夢芝居だ」
俺と富美男は、夜が明けるまで、何度もなんどもお互いを求め合った。 本番データの登録でseederは草
普通にsql使えよｗ seederのほうがlaravelのみで管理できるからそっちのほうがいいと思うけど
sqlだとそのsqlファイルをpublicとかに配置しないといけないよね？ >>918
多分ネタだろうから相手にしないほうがいいぞ
本気で言ってるなら理由を書くからな
ネタで言ってるやつはみんな理由を書かない
このスレの掟な >>918
別にpublicに配置する必要なくね？
mysqlに接続して用意しておいたSQL実行すればいいやん
別にseederでも問題ないと思うけどね
俺は開発用のデータとごっちゃになるからやらんけど すみません教えてください
laravelを使っていてcakephpにしかない機能が使いたい場合があります
その場合laravelにcakephpをcomposerでインストールすれば
cakephpでlaravelが使えるようになりますか？ laravelでcakephpを使えるようになるかということでござったが
くっ…書き間違いをしてしまったようでござるな…
失敬！ﾄﾞﾋｭｰﾝ その機能の具体的なパッケージ名やクラス名を書いてくれないと答えようがないと思うんだが…w
まぁ解決したようだし良いか では自分も質問です
Laravelを選ぶ利用の一つとして、フレームワークが持つ豊富な機能と、
静的メソッドに見えるファサードという記法がみやすく、分かり易いEloquentORMという点が挙げられると思います。
このEloquentとファサードは賛否いろいろ意見はありますが、
アプリケーションのモックや、小規模アプリケーションでは使い勝手が良く、
ある程度動かすところまで開発するには大変便利だと思います。
複数人で開発を行い、長期的に運用、保守していかなければならないような場合に、この機能とどう付き合っていくべきでしょうか？
ベストプラクティスがあれば教えてください >>927
具体的な問題点と期待値は何ですか？
それとも感想が欲しいだけ？ >>927
ベストプラクティスなんて無いぞ。ある程度の規模の開発ではeloquentとファサード使うな！はアイスタイルってスタートアップが提唱してたけど、単に杜撰な設計をFWの機能のせいにしているだけかなって。
むしろヤバいのは、モデルクラスの便利機能だな。アクセサとミューテータ。ここは容易にカオスになっていく。 eloquent使うなと言うのは乱暴だよなぁ
それなら別のフレームワークでええやんと思う >>936
これまるで参考にならんやんw
こんなこと言ってる奴なんて殆どいないやろ うちは逆に素のSQL書くなって新人に教えてるわ
インジェクション可能なコード書かれたらたまらん、コードレビューしても見落としはあり得るし 優秀なプログラマ集めるのが一番速いし、
これが無理なら諦めてごちゃごちゃ覚悟でやるしかないよ sqlインジェクションってORM使ってたら大丈夫なんじゃないの？ 優秀なプログラマ集める←これが一番不可能だし
優秀なプログラマでもミスはするから、ミスが起こり得ない仕組み作りが重要 無理なもんは無理だからな
もうフレームワークなんて何でも良いし、そんなことすら考えずにNTT DATAに丸投げがよい eloquentの是非はどうでもいいがSQLインジェクション気にするならWAFくらい入れろよ >>937
せやで。ここまで来るとLaravel使う必要ある？て思うしな。 受託だとLarevel使えって指定する客がいるんだよな
普及しててメンテしやすいとかそういう理由だろうが 単にPHPフレームワークで1番メジャー = 長く生き残りそう、てだけの判断じゃね？ おめーらさんたちはLaravelで何を作っとるの
世の中には認知されない程度のアプリ？ laravelはデフォルトの認証だとメールアドレスとパスワードによるログインですが
これをユーザIDとパスワードによるログインに変更することは可能でしょうか？
可能であればどのように行えばよいでしょうか 別にemailにはなってるけど何入れてもいいよ
ただしバリデーションやら初回の認証にメール送ったり、パスワードリセットでメール送るような実装があるならそこは書き換えないといけないが ソース見たらわかるけどどのカラムをユーザーIDとするか定義してるところを変えたら変えられる >>953
selectはeloquentダメなのか？どうして？ >>951
カラムをユーザIDに変更可能なこと知らないんですか！？ Eloquentにはsaveとupdateの２つでデータの更新を行うことが可能ですが
updateは必ず更新が実行される
saveはデータに差異がある場合のみ更新が実行される
という理解でいいですか？
また基本的にはsaveのほうを使用してupdateは使わないほうがいいという
理解でいいですか？ >>956
さすがにネタだろ。「emailてカラム名だけど、どんな値入れても良い」とか脳みそ腐ってるレベルの発言を素で言ってたらヤベー奴じゃん。 emailカラムのままID入れるってことかw
このスレはマジでぶっ飛んでるなw いやemailにIDぶち込むのはいい手法だと思うけど
ユーザIDで認証させるためにvendor直下のファイルをいじくるほうが危なくないか？ >>960
いやオーバーライドしろよ
魔窟かよこのスレ >>958
266 nobodyさん sage 2021/04/01(木) 09:28:10.06 ID:???
公式マニュアルや自分の知る方法だけが正しいと信じて守らない新人をバカにする
そういう輩が将来真っ先に老害になるから気を付けろよ >>962
266 nobodyさん sage 2021/04/01(木) 09:28:10.06 ID:???
公式マニュアルや自分の知る方法だけが正しいと信じて守らない新人をバカにする
そういう輩が将来真っ先に老害になるから気を付けろよ 俺ぐらいになるとphpのcのソースいじってコンパイルぐらいするぞ ゴミクソ野郎ばっかだなphperは
常に紳士でありながら意識高いRubystとは大違い やばいよこのスレw
>>960 とかまさか職業プログラマーとかじゃないよな？w >>960
LoginControllerでusernameメソッドをオーバーライドすればいいってちょっとググれば出てくるだろ うちの場合はクライアントからLoginControllerを修正しないでくださいって言われてるからemailにそのままユーザーの識別子をいれるよ、あと本番デプロイの都合もあるからね。
しかもLoginControllerを修正するとドキュメントを修正する工数も請求しなきゃいけないし。
たまには他のやり方も認めたら？老害君 うちはartisanで自動的に作られたCRUD以外は申請が必要になる
自動生成が一番リスク低いからな
コード書くとか雑魚の仕事でしょ？ 個人的にはusername関数オーバーライドも正直気になる
それが一番正解なんだけどusernameという関数名なのに実際は
ユーザIDをリターンすることになるから関数名と処理の名前が合わないというか email返すのもおかしいじゃん
あれはログインユーザー名に使うカラム名を返す関数だから別にいいでしょ 具体案も言わずに発狂してる奴ってw
>>958みたいな奴ってマジで何も出来なさそうw 強制ワッチョイでスレ立てようとしたら
ERROR: 使えません。(BBS_USE_VIPQ2=0)
って言われた
本当に終わりじゃん
意訳：extendsコマンドの使用にはBBS_USE_VIPQ2が2以上必要ですが、この板の設定ではBBS_USE_VIPQ2が0なので失敗しました。 >>981
糞板だな、プログラム板はいけるっぽいし移住しようぜ
https://mevius.5ch.net/tech/
php質問スレもあるし問題ないだろ とりあえずこのスレには、ゴミみたいなクライアントの言いなりになってるコーダーが何人か居るんだなぁ。まぁ俺には関係の無い世界だわ。 俺は本業は自社サだし、副業も知り合いの案件しか受けてない。なのでどの仕事も設計から自分に決定権あるやつのみだわ。 言われたことを言われたとおりにやろうとしてゴミが出来上がる
提案する能力もない奴の給料は低い >>987
所詮底辺のコーダーてことだろうし、それをおかしいとも思わず批判されたら老害呼ばわりだから、救いようがないよね。 ここでアホなこと書いてる奴の大半はネタだろ
まぁ一部ガチも居るかもしれんが githubの無償アカウントでプライベートリポジトリ作れないと思ってた奴は、ガチぽかったな。 >>973
ログインコントローラー弄りたくないならログインコントローラー継承クラス作ってルーティング差し替えればいいじゃん >>996
ちょっと前のレスで経緯話されてるじゃん…少しは遡れよ このスレなくなったらこの板終わりやん
この板で唯一勢い1.0超えてるスレやぞ（ネタスレクソスレ2つを除く このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 61日 16時間 20分 14秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
