将来を見据えたウェブ・アプリケーションの構築:The Codestのエキスパート・チームによる洞察
The Codestが、最先端技術を駆使してスケーラブルでインタラクティブなウェブアプリケーションを作成し、あらゆるプラットフォームでシームレスなユーザー体験を提供することにどのように秀でているかをご覧ください。The Codestの専門知識がどのようにデジタルトランスフォーメーションとビジネス...
もしあなたがソフトウェア開発者なら、おそらくすでにご存知だろうが、あなたの数ある役割のひとつは、車輪の発明家になることではない。少なくとも、ほとんどの場合はそうではない。
について書きたい。 JavaScript に依存する。しかし、最初から始めよう。もしあなたがソフトウェア開発者なら、すでにご存知だろうが、あなたの数ある役割のひとつは、車輪の発明家ではない。少なくとも、ほとんどの場合はそうではない。今日、ほとんどすべてのパッケージが存在し、私たちの開発をより簡単かつ効率的にしてくれている。
もちろん、これは他の問題への関心を失うことを奨励するものではない。しかし、あなたのビジネス目標は、完全な 製品 時間ぎりぎりに、あるいは時間前に、お皿に盛る。パッケージは、そのような計画を実現し、以下をもたらす。 npm または ヤーン しかし、どんな解決策も、この解決策と同様に、リスクをもたらす可能性がある。以下の記事でそれを説明し、より良い方法を紹介しよう。
大型のJavaScriptを想像してほしい。 プロジェクト.ビジネス上の要件により、開発者は特定のパッケージを使用することが義務付けられ、クライアントの別のシステムとの適切な統合が可能になる。それはまったく問題ない。 最優秀選手 次の契約が締結され、開発が進められている。.クライアントは、システムの次の部分を統合するように要求し、それはあなたのパッケージの更新を必要とします。
テストが始まるまでは、この部分はうまくいく。このパッケージには、単純だが不便なバグが含まれているようだ。 を修正することはできない。 ノードモジュール ディレクトリ - そのため、共同作業者はあなたの変更について何も知ることはありません!さて、これを読んでいる間に、おそらくあなたはもう何をすべきか理解したことでしょう。しかし、本当にそのようなハンマーが必要なのでしょうか?
あなたが直面している問題が、あなただけの問題なのか、それとももっと大きなコミュニティーに関わる問題なのかを認識しておく必要がある。ある機能の欠如をバグと解釈する人がいますが、それは必ずしも正しいとは限りません。ですから あなたのソリューションはコミュニティに受け入れられず、公式リポジトリに含まれない可能性があります。.しかし、今ここでまだ必要なのだ。さて、パッチを当てよう!
githubリポジトリのリリースノートによると、patch-packageは以下の通り。 )が2017年5月に正式にリリースされた。Itは強力なツールで、依存関係のあるプロジェクト内の変更を、あなたの ノードモジュール ディレクトリ.インストールコマンドを実行すると、依存マネージャーが変更を上書きしてしまう。
まあ、これは正しい。しかし、パッチ・パッケージは npm そして ヤーン のスクリプト準備("script": { "prepare":""})を最大限に活用します。 package.json ファイル。 Patch-packageは文字通り、実際のプロジェクトのpatchフォルダに格納された、あなたの変更とオリジナルパッケージの差分ディレクトリを作成します。.
インストールコマンドを実行し、すべての依存関係をダウンロードした後、プロジェクトディレクトリにその差分を適用し、すべての共同作業者のためにあなたの変更を完璧に再現します。あなたの生活がよりシンプルになりますね。この解決策には欠点もあります。patch-packageは、あなたのパッケージの依存関係を修正することができません。 package.json.
この場合、forkソリューションを使うことができる。また、あなたが依存関係のあるパッケージに適用しようとしている変更の数と、それがやがて大きくなるかどうかを考慮しなければなりません。もしそうなるのであれば、forkを使うときは慎重に考えるべきです。
パッチは、無限のフォークを作成したり、複数のプロジェクト・ソースを生成したりすることなく、依存関係を修正する素晴らしい方法です。しかし、コミュニティを利用することは一方向的なものであってはならないということを常に覚えておくべきだ。 バグを見つけたり、使っているパッケージを改善できそうだと感じたりしたら、issueを登録したり、あるいはプロジェクトに貢献することで、他の人を助けることを常に考えるべきです!