⇧ 時の流れの前には、すべてのものは、塵に還るんだと。
海外とかだと、死者を弔う際に、
earth to earth, ashes to ashes, dust to dust.
⇧ って言葉を聞くけども、時が経てば、やがて、万物は還るべき場所へ還っていくという考え方は、結構、万国共通なんですかね？
By the way、「JavaScript」のフレームワーク、乱立してましたよね、まさに、盛者必衰の理じゃないけども。
で、2020年は、一体、状況はどんな具合だったんだい？と。
VueのTypeScript対応が完了した今、これから勉強してWebアプリを作りたい！という人にとっては、なかなかVueとReactどっちを取るかというのは難しいなぁと思いました。
サクッと作るならVueのほうが絶対コスト少ないと感じるので。
一方で長期的に考えたとき、将来のフレームワーク乗り換えのリスクなどを考えるとやはりReactが無難だとは思います。
今はとりあえずReact（もちろんReact Hooksと一緒に）を使っておくのが最善そうですね。
なぜ svelte がマイナーで新しいライブラリにも関わらず世界では Vue.js を上回る関心が持たれているかというと、作者が rollup の開発者でもあるリッチハリスということで品質がある程度担保されていることと、課題解決のアプローチが React, Vue.js とは全く異なるためです。
⇧やっぱり、「Vue」「React」のシェアが圧倒的らしいですね。
「Angular」が敬遠されがちな理由が、
Ruby on Railsが人気を無くした理由は、フルスタックフレームワークだからという点がとても大きいと筆者は考えていて、Angularが不人気なのもその点が大きいでしょう。同様にNuxtもそうなりうる危険性があるように見えます。
フルスタックフレームワークは、Ruby on Rails界隈ではなぜかTDDが死んだことになっているくらいには、ユニットテストとの相性が悪くなってしまう仕組みです。
⇧ ってことがあるのではないかと仰ってますね。
つまり、フルスタックであるから、何でもできるし高機能なんだけど、その分、フレームワーク自体が巨大なので、学習コストも高いし、将来的に他のフレームワーク移行せざるを得ない状況になった時もコストが高く付き、まさしくハイリスクハイリターンってことが考えられるんじゃないかと。
しかも「Angular」の開発スピードが早いことも、いくらアジャイル的な手法が浸透してきたとはいえ、アプリケーションの開発現場で敬遠される理由の1つでないかとも思えるんですよね。
何か問題が起きた時に、頼りにできる情報が得られにくいという状況は極力無くしたい、リスクヘッジを常に考えなければならないのが開発プロジェクトには必須だと思いますし。
2021年はと言うと、
目的があるなら別ですが、2021年にとりあえずJavaScriptを始めてみたい、という段階であれば、ReactかVue以外の選択肢はありません。
⇧ 初学者が着手するなら、「React」か「Vue」を選択し解けば安牌らしい。
といわけで、レッツトライ～。
JavaScriptフレームワークは何故に乱立したのか
「JavaScript」のフレームワークってむちゃくちゃ多いですよね。
これには、様々な要因があるようなんですが、
- JavaScriptが元々はブラウザでの利用が前提だった（今はサーバサイドも可）
- 仕様が存在しなかった（ECMAScriptできてからは頑張ってる）
- クロスブラウザの問題
あたりが、主要なものになるのではないかと。
なので、乱立してしまったのは、ある種の善意からだったとは思うんですよね、これを作ったら皆が開発しやすくなるんじゃないかっていう。
ただ、如何せん、元々の土壌が荒れ果てていたこともあり、洗練されるまでに、先人たちの試行錯誤が積み重なった結果、膨大な数々のフレームワークが爆誕しては、消えてゆくということの繰り返しの果てに、過去を振り返った時に、「JavaScript」のフレームワークむっちゃ多いなって感じる状況が出来上がったのだと。
2021年から利用していくなら？
この記事を書き始めてから時間が経過してることもあり、2021年も残り僅かになってしまっているのですが、いろんな情報を見てる限り、
- React
- Vue
- Angular
の3つのいずれかになってくるのだとは思うけれど、これから学習を始めるって場合は、「React」か「Vue」を選択しとけば無難らしい。
⇧ 注目度とかで集計してくれてる状況を見てみても、「React」と「Vue」は右肩上がりになっているので、余程の「ゲームチェンジャー」が起きない限りは、しばらく廃れることはないのではないかと。
ただ、最近、「jQuery UI」「jQuery Mobile」が事実上、終焉する流れが。
JavaScriptのUIフレームワークであるjQuery UIと、モバイルアプリケーション向けフレームワークであるjQuery Mobileは今後新規機能の開発が行われず、jQuery UIについてはメンテナンスへ移行、jQuery MobileについてはDeprecated（利用を推奨せず）になることがOpenJS Foundationから正式に発表されました。
jQuery UIとjQuery Mobileがついに開発終了、今後はメンテナンスのみに。jQuery本体は引き続き積極的に開発 － Publickey
jQuery UIは2007年に登場、jQuery Mobileは2011年に登場しました。一時期はWebサイトなどで広く使われ、関連書籍なども数多く出版された主要なライブラリ群の開発が正式に終わることになります。
jQuery UIとjQuery Mobileがついに開発終了、今後はメンテナンスのみに。jQuery本体は引き続き積極的に開発 － Publickey
ただしjQuery本体の開発は引き続き積極的に行われていくとのことです。
jQuery UIとjQuery Mobileがついに開発終了、今後はメンテナンスのみに。jQuery本体は引き続き積極的に開発 － Publickey
⇧ う～ん...これまでに学習してきた技術が唐突に白紙にされるという、この計り知れない徒労感たるや、筆舌に尽くしがたいですよね...
とは言え、将来どうなるかなんて誰にも分からないので、技術選定の難しさが発生するわけですよね。
なので、可能であれば「学習コスト」が抑えられる技術を採用したいところですね。
その前に、JavaScriptが処理される仕組みって？
元々、「JavaScript」ってフロントエンド側よりってイメージだったと思うんだけど、「Node.js」ってものが出てきたあたりから、なんとなく雲行きが怪しくなったような気がするけども、
- front-end developer
- front-of-the-front-end developer
- back-of-the-front-end developers
ってな感じで、フロントエンド側の作業が細分化されてきてるということらしい。
⇧ 上記サイト様が詳しいです。
なので、正直、最近のフロントエンドの仕組みがよく分からんのだけど、昔ながらの考えだと、
⇧ ってな感じで、最終的に、「JavaScript」のファイルは、「Web Server」で処理されるってことだとは思うんだけど、
⇧ 最終的には、「Web Server」で処理されたファイルのデータが、「ブラウザ」に搭載されてる「JavaScript」エンジンでレンダリングされて、Webページとして表示されるってことなんかね？
ただ、
⇧「SSR（Server Side Rendering）」なる仕組みもあるようで、いろいろ状況は変わっているようですね。
JavaScriptフレームワークのデプロイ先って？
で、通常の「JavaScript」ファイルなんかは、「Web Server」にデプロイしとけば良さ気っぽいように見えるんだけど、「React」や「Vue」みたいなJavaScriptフレームワークのファイルってデプロイどうするんだろうね？
その前に、「React」や「Vue」ってのは、「TypeScript」っていうファイル形式が利用できるらしいんだけど、「TypeScript」とは？
TypeScript はマイクロソフトによって開発され、メンテナンスされているフリーでオープンソースのプログラミング言語である。TypeScriptはJavaScriptに対して、省略も可能な静的型付けとクラスベースオブジェクト指向を加えた厳密なスーパーセットとなっている。
TypeScriptはクライアントサイド、あるいはサーバサイド (Node.js) で実行されるJavaScriptアプリケーションの開発に利用できる。
TypeScriptは大規模なアプリケーションの開発のために設計されている。
TypeScriptはJavaScriptのスーパーセットであるため、既存のJavaScriptプログラムは、全て有効なTypeScriptプログラムとなる。
⇧ ってな感じで、JavaScriptに「静的型付け」な機能と、「クラスベースオブジェクト指向」を付与できるっていう点が、大規模な開発で利用される要因なんかな？
ちなみに、
現在のECMAScript言語標準が将来的にクラスベースオブジェクト指向をサポートする提案があることを踏まえ、TypeScriptはその提案に基づくことになった。これにより、その提案に基づいたスーパーセットであり、幾つかの点で言語の文法を拡張したJavaScriptコンパイラへと至ることとなった。このコンパイラが、言語を拡張した部分を一般的な JavaScriptへと変換する仕組みである。
⇧ ってな感じで、最終的には「ECMAScript」で「クラスベースオブジェクト指向」が仕様として定義されるかもな話が出てたってことらしいんだけど、今どういう状況なのかね？
そして、
TypeScriptコンパイラtsc自体もTypeScriptで作成されている（セルフホスティング）。これは通常のJavaScript にコンパイルでき、任意のホスト上のJavaScriptエンジン（たとえばブラウザなど）上で実行できる。ライセンスは Apache License 2.0である。コンパイラ・パッケージはコンパイラを実行出来るスクリプトホストに同梱されてくる。Node.js等と共にコンパイラ・パッケージとして配布される場合もある。
⇧ ってな感じで、「TypeScript」形式のファイルは、「JavaScript」形式のファイルにコンパイルされることで、ブラウザに搭載されてる「JavaScript」エンジンが処理できる感じですと。
なので、最終的には、「JavaScript」形式のファイルにするってことみたいなので、「JavaScript」フレームワークで開発した成果物も、Web Serverにデプロイする感じになるんかな。
このあたりの
- JavaScript
- ECMAScript
- TypeScript
の関係性については、
⇧ 上記サイト様の図が参考になるかと。
「静的型付け」を実現するには「TypeScript」が必要なんだけど、「TypeScript」は「ブラウザ」で実行することができないから、「TypeScript」を使うんなら「コンパイル」して「JavaScript」ファイルにしてねってことらしい。
で、ややこしいのが、
題名の通り、typescriptとnode.js、webpackの関係性についてイマイチパッとしません。
自分なりに考えて以下のイラストを作ってみたのですが、図と以下の認識は間違っているでしょうか。
- typescriptで記述されたものがトランスパイルされてjsファイルになる
- jsファイルになることで、ブラウザがファイルを認識できるようになる
- 「サーバーとのやり取りをしない」ならば、node.jsを使用する必要はない
- node.jsを使用すると、フロントエンドとサーバー側のやり取りができるようになる（ユーザーからデータを受け取ってデータベースに保存するなど）
- 「ファイル同士の依存関係を自分たちで何とか解決できる」ならば、webpackを使用する必要はない
- webpackを使用すると、複数のjsファイルが依存関係を解決しつつ一つにまとめられる
- 「サーバーとのやり取りをしない」、「ファイル同士の依存関係を自分たちで何とか解決できる」ならば、node.jsもwebpackも使用する必要はない
ここは違う、こう理解した方が良い、付け加えると...等ありましたら、教えていただけると幸いです。
⇧ という質問に対して、回答が
この場合、Node.jsはコンパイラやWebpackを動かすために前提のプログラムとして必要となります。
WebPackはTypeScriptを読み込み、（ローダーといいます）
依存関係を解消してJSファイルにコンパイルすることもできます。
⇒ 別途コンパイラが必要ない
⇧ とあるように、「コンパイル」は「tsc」以外でも可能らしいというね...
なんか、「Babel」ってのもあるみたいだし、なかなかに混沌としておりますな...
でも、何だかんだで、最終的に「JavaScipt」ファイルにするってことは、従来通りの配置場所と変わらないってことなんかな？
つまり、何かしらの「Web サーバー」上に配置すれば良いのかしら？
「Vue.js」のプロジェクトの場合、
If you are developing your frontend app separately from your backend - i.e. your backend exposes an API for your frontend to talk to, then your frontend is essentially a purely static app. You can deploy the built content in the dist directory to any static file server, but make sure to set the correct publicPath.
The dist directory is meant to be served by an HTTP server (unless you've configured publicPath to be a relative value), so it will not work if you open dist/index.html directly over file:// protocol.
⇧ ってな記載があって、最終的にビルドされたファイルは「dist」ディレクトリに配置されるらしく、そのファイルを「static file server」に配置すれば良いとなっているのだけど、ビルドの仕組みとか含めて、どこに配置すれば良いかを知りたいんですけどね...
Vue.jsを使ってみる
何はともあれ「Vue.js」を使ってみようかと。
正式名称なのですが、「Vue」なのか「Vue.js」なのかがよく分からんのですが、Wikipediaさんによると、
Vue.js（ヴュー・ジェイエス）またはVueは、Webアプリケーションにおけるユーザーインターフェイスを構築するための、オープンソースのJavaScriptフレームワークである。
他のJavaScriptライブラリを使用するプロジェクトへの導入において、容易になるように設計されている。一方で高機能なシングルページアプリケーション（SPA）を構築することも可能である。
VueはGoogleにおいてAngularJSを使用した開発に携わったエヴァン・ヨーによって開発され、2014年2月にリリースされた。ヨーは「Angularの本当に好きだった部分を抽出して、余分な概念なしに本当に軽いものを作ることができたらどうだろうか？」と考えていた。
⇧「Vue.js」または「Vue」って説明になっていて、どっちでも良いってことなんかな？「Angular」に影響されてるらしいという、まさかの事実には驚いたけど。
⇧「2020年12月4日閲覧」時点では、注目度が一番多かったみたいね。
「GitHub」で公開されてる「Vue」についての情報を見てみると、
⇧リポジトリ数が120とかボリューミーなんですが...
というか、「Vue.js」でもなく「Vue」でもなく「vuejs」という表記が...正解はどれなん？
まぁ、とりあえず、「ブラウザ」で表示することだけが目的であれば、「TypeScipt」は必要ないみたいなんだけど、「Vue」を使うには「Vue.js」なるものを導入しなければならないですと。
で、導入方法はというと、「Vue.js」の「バージョン3」のドキュメントによると、
Installation
Vue.js is built by design to be incrementally adoptable. This means that it can be integrated into a project multiple ways depending on the requirements.
There are four primary ways of adding Vue.js to a project:
- Import it as a CDN package on the page
- Download the JavaScript files and host them yourself
- Install it using npm
- Use the official CLI to scaffold a project, which provides batteries-included build setups for a modern frontend workflow (e.g., hot-reload, lint-on-save, and much more)
⇧ ってな感じで、「Vue.js」を利用する方法としては、4つのやり方があるらしい。
で、「npm」を使って「Vue.js」を導入していく場合は、「npm」を利用できるようにする必要があり、「Node.js」を導入していく必要があるんですな、っていうか「npm」を使うには「Node.js」が必要っていう情報が端折られてるよね～...
そもそもとして、「バージョン」によって違いあるんじゃないの？って思っていたら、案の定、かなりの差異があるみたいです...
⇧ 上記サイト様が記事を公開した時期にはサポートされていなかったらしい「Nuxt」 の「Vue3」対応については、
⇧ あくまでも「β版」という扱いでサポートするという記事が「2021年10月12日（火）」に公開されてました。
ちなみに、「Vue.js」の公式の「バージョン2」のドキュメントによりますと、
What is Vue.js?
Vue (pronounced /vjuː/, like view) is a progressive framework for building user interfaces. Unlike other monolithic frameworks, Vue is designed from the ground up to be incrementally adoptable. The core library is focused on the view layer only, and is easy to pick up and integrate with other libraries or existing projects. On the other hand, Vue is also perfectly capable of powering sophisticated Single-Page Applications when used in combination with modern tooling and supporting libraries.
If you’d like to learn more about Vue before diving in, we created a video walking through the core principles and a sample project.
⇧ ビデオで「Vue.js」の「core principales」を説明してるとあって、「created a video」のリンクをクリックすると、ビデオが視聴できるのですが、
⇧ 5つの思想があるらしく、
⇧ 基本的には、画面を構成する「コンポーネント」単位で、ファイルを分けていくのを理想とするみたいなニュアンスですかね。
だいぶ、脱線しまくりましたが、今回は、「バージョン2」の「Vue.js」を利用してみることにします。
「バージョン2」の「Vue.js」の導入方法はどうなっているのか、
⇧ 公式のドキュメントを見た感じでは、
の4つの方法があるということで、「バージョン3」と変わらずの模様。
で、このうち、「NPM」もしくは「CLI」で「Vue.js」を導入する場合は、「Node.js」が必要となるらしい。
というわけで、「Node.js」ですが、私の記憶が確かなら昔にインストールしたはず、ということで確認してみたところ、
⇧ バージョンがかなり古い...
ちなみに、Windowsに「Node.js」をインストールする場合、
Windows または WSL のどちらにインストールするかを選択するだけでなく、Node.js をインストールするときには他にも選択することがあります。 バージョンの変更は非常に早いため、バージョン マネージャーを使用することをお勧めします。 多くの場合、作業しているさまざまなプロジェクトのニーズに基づいて、複数の Node.js のバージョンを切り替える必要があります。 ノード バージョン マネージャー (一般的には nvm と呼ばれています) は、複数のバージョンの Node.js をインストールする場合の最も一般的な方法ですが、Mac または Linux にのみ使用でき、Windows ではサポートされていません。 代わりに、ここでは、nvm-windows をインストールし、それを使用して Node.js と Node Package Manager (npm) をインストールする手順について説明します。
⇧ とあるように、「WSL 2（Windows Subsystem for Linux 2）」の環境にインストールしたほうが良いのらしいだけど、そもそも「Node.js」のバージョンを管理するような「ノード バージョン マネージャー」と呼ばれる「nvm」で「Node.js」のインストールを行うのが良いらしく、ただ、Windowsでは「nvm」が利用できないという哀しい宿命なので、代わりの手段が、「nvm-windows」というものらしい。
で、私の記憶が確かなら、それも昔にインストールしたな～、って思って確認してみたところ、
⇧ バージョンがかなり古い...ってこともなく、というのも、「nvm-windows」のリリースノートを確認してみると、
In September 2021, Node.js v16.9.0 introduced corepack. This experimental new feature allows transparent use of npm, pnpm, or yarn. To support this feature, NVM4W must download and process a different distribution file than it has used previously.
As a result, NVM for Windows 1.1.8 is being released to support corepack.
⇧「2018年8月2日」を最後に暫く開発が止まっていたらしいのですが、「Node.js」が「corepack」なるものを導入した影響で、「nvm-windows」にも手を入れる必要が生じた結果「2021年9月15日」に「バージョン 1.1.8」がリリースされたということらしい。
じゃあ、これらをインストールしていこうと思ったのだけど、私の記憶が確かなら、Windowsで使える「パッケージ管理ツール」としては、
- winget（Windows Package Manager）※
- chocolatey
- scoop
- ※2021年10月13日（水）時点では正式リリースされてない
あたりがメジャーどころかと思われますが、「パッケージ管理ツール」で「nvm-windows」をインストールし、「nvm-windows」で「Node.js」をインストールする流れですかね、面倒くさいことこの上なし。
ちなみに、「winget」は手前味噌になりますが、
⇧ 上記の記事で、「winget」を導入してます。
ただ、2021年10月13日（水）時点でも「正式リリース」はされていないので、微妙に思う方は、「chocolatey」か「scoop」とか使うのが良いかと。
「winget」がインストールできたかどうかは、バージョン確認でOKっぽい。
「winget」については、
⇧ Microsoftさん公式のドキュメントがある模様。
だいぶ、脱線しましたが、『見せて貰おうか。Windowsの正統なパッケージ管理ツールを謳う「winget」の性能とやらを』ということで、「winget」で「nvm-windows」をインストールしようとしてみたものの、
⇧ 悲報...そんなパッケージは存在しないと...というか、「nvm」でヒットするのが「CrystalDiskInfo」ってさ...、最早バグ？
唐突に「winget」による管理の限界を告げられるという、まさかの結末...
そもそもとして「winget」側で「nvm-windows」をどういう「名前」で管理してるのかを確認する術がないところが辛いですな...
これが「winget」の実力か、ということで、こんなこともあろうかとインストールしておいた「chocolatey」で対応することにします。
とりあえず、「chocolatey」自身のアップグレード。
管理者権限でコマンドプロンプトを起動して、
choco upgrade chocolatey
そしたらば、「nvm-windows」がインストールできるパッケージとして存在するのか確認。
choco search nvm
⇧ 紛らわしいことこの上ないけど、「chocolatey」の世界では「nvm」が「nvm-windows」のことらしい...
ただ、「バージョン 1.1.8」は、まだ「chocolatey」でインストールできるパッケージになっていない模様。
Windowsの「パッケージ管理ツール」の貧弱さたるや...もう、涙なくして語れない...
ちなみに、「chocolatey」でインストール済み（自分のPCにインストールされてる）の「パッケージ」の一覧を確認してみたところ、
choco list --local-only
⇧ ローカル環境に「nvm」はインストールされていないとのことなので、現在、PCにインストールされてる「nvm-windows」は過去の自分が手動でダウンロードしてインストールしたということになるらしい、全く記憶にないという...。
というわけで、一応、「chocolatey」でインストールしておきます。
ちなみに、自分の環境では、手動でインストールした「nvm.exe」と、「chocolatey」でインストールした「nvm.exe」と2つが存在することに...
⇧ 手動でインストールしたものについては面倒を見てくれないってことですね...
では、「nvm-windows」で「インストール可能なパッケージ」「インストール済のパッケージ」を確認するコマンドを「Node.js」について実行してみます。
nvm list available node
nvm list installed node
⇧ という感じで、自分のPCには「10.15.0」「8.9.4」の「Node.js」がインストールされていて、「8.9.4」が有効になっているらしいですと。
で、肝心の「Vue.js」の「バージョン 2系」に必要な「Node.js」の「バージョン」が分からんというね...
Warning regarding Previous Versions
The package name changed from vue-cli to @vue/cli. If you have the previous vue-cli (1.x or 2.x) package installed globally, you need to uninstall it first with npm uninstall vue-cli -g or yarn global remove vue-cli.
Node Version Requirement
Vue CLI 4.x requires Node.js version 8.9 or above (v10+ recommended). You can manage multiple versions of Node on the same machine with n, nvm or nvm-windows.
⇧「Vue CLI 4.x」ってのが「Vue.js」のどのバージョンで使えるのかが分からん...
というか、「Vue CLI」の「バージョン」と「Vue.js」の「バージョン」の対応表みたいなの作ってくれてると助かるんですけどね...
WARNING
This documentation is for @vue/cli. For the old vue-cli, see here.
⇧ ってな情報がありまして、
vue-cli is deprecated, see the new documentation.
⇧ 見た感じ、「Vue.js」の「バージョン2」のガイドで「vue-cli」は「非推奨」ってなってるので、当然「Vue.js」の「バージョン2」で「@vue/cli」が使えないとも書いていないので、「Vue CLI 4.x」が「Vue.js」の「バージョン2」でも使えると信じるしかないですな、それにしてもドキュメントが分かり辛い...
とりあえず、「Vue CLI 4.x」使う場合の「Node.js」のバージョンについては「v10+ recommended」って言ってるので、インストール済みの「Node.js」で「10.15.0」のほうに切り替えれば問題なさそうなので、バージョンを切り替えます。
で、「npm（Node Package Manager）」については「Node.js」をインストールすると「Node.js」に同梱されてくるらしい。
To publish and install packages to and from the public npm registry or a private npm registry, you must install Node.js and the npm command line interface using either a Node version manager or a Node installer. We strongly recommend using a Node version manager like nvm to install Node.js and npm. We do not recommend using a Node installer, since the Node installation process installs npm in a directory with local permissions and can cause permissions errors when you run npm packages globally.
https://docs.npmjs.com/downloading-and-installing-node-js-and-npm
⇧「nvm」を使って「Node.js」をインストールすることを強く薦めるって太字になってますな...
で、一応、「npm」のバージョン確認してみたけども、
⇧「Node.js」と「npm」のバージョンの対応表とか無いんかね...
適正なバージョンなのか確認しようがないんだが...
と思ったら、早見表を見つけました。基準が無ければ比較のしようが無いからね...
⇧ 自分の環境にインストールされてる「Node.js」のバージョンと「npm」のバージョンは適切なようです。
この対応表とかもコマンドで確認できれば嬉しいんですけどね。
脱線しまくりましたが、ようやく、「Vue CLI」をインストールする準備が整ったようですが、「npm」コマンドで「-g」オプションを付けるべきなのかどうかがよく分からん...
The g in npm install -g is a flag signifying that you want to install that particular npm module system wide (globally). Without the g option, the module would be installed locally inside the current directory called node_modules -try it!
npm install -g <package-name> attempts to install the package into a system-wide node_modules directory (for Mac, this would be "/usr/local/lib/node_modules")
⇧ 毎回思うけど、Windowsを除け者にするの止めて欲しい...
⇧ 上記サイト様により、Windowsの場合に「-g」オプションで「npm install」した場合の「パッケージ」の格納先のディレクトリが朧気ながら分かったのだけど、そもそも「-g」を付けた方が良いのか付けない方が良いのかは依然として分からず...
⇧ 上記サイト様によりますと、「-g」オプション付けてしまうと環境依存してしまう可能性が大きいということみたいですね。
確かに、開発環境が「Winodws」で本番環境が「Linux」って言う状況はありますからね（前の現場がまさにそうだったのですが...）
ただ、
グローバルインストールは、PC上のどのディレクトリからもコマンドが実行できる場所（PATHが通った場所）にインストールされます。特定のプロジェクトではなく、プロジェクトを問わずよく使う可能性のあるコマンドは、グローバルインストールしておくと便利です。
ただし、プロジェクトに依存しないコマンドとして使いたいツールなら良いですが、PCのどこからでも使えるようにインストールするという仕組み上、プロジェクトごとにバージョンを切り替えたりはできません。また、同じプロジェクトのメンバーとインストールするツールを揃えるのも難しくなるので注意しましょう。そういった用途では、次に紹介するローカルインストールがおすすめです。
⇧ やはり、「-g」オプションは避けたほうが良い気がしますね...。
プロジェクトを掛け持ちしたりしてて、「Vue.js」のバージョンが違ってた場合、「-g」オプション使ってたりすると厄介なことになりそうですし...
というわけで、今回は、「ローカルインストール」で。
まずは適当な場所にディレクトリを作成して、
コマンドプロントで、いま作成したディレクトリまで移動して、「Vue.js」のモジュール群を「ローカルインストール」で。
npm install @vue-cli
⇧ 正常にインストールできたの？ってぐらい、「WARN」「deprecated」の雨あられなんですけど...
一応、モジュール群はインストールされたらしい。「package-lock.json」なるファイルもできてますね。
「package-lock.json」とは？
This file is intended to be committed into source repositories, and serves various purposes:
-
Describe a single representation of a dependency tree such that teammates, deployments, and continuous integration are guaranteed to install exactly the same dependencies.
-
Provide a facility for users to "time-travel" to previous states of
node_moduleswithout having to commit the directory itself. -
Facilitate greater visibility of tree changes through readable source control diffs.
-
Optimize the installation process by allowing npm to skip repeated metadata resolutions for previously-installed packages.
-
As of npm v7, lockfiles include enough information to gain a complete picture of the package tree, reducing the need to read
package.jsonfiles, and allowing for significant performance improvements.
https://docs.npmjs.com/cli/v7/configuring-npm/package-lock-json
⇧「npm install」でインストールされた「パッケージ」を管理するために必要なファイルということらしい、というか「node_modules」って名前だけど、インストールされたものは「モジュール」じゃなくて「パッケージ」と呼ぶらしい...う～む、ややこしい...。
そして、コマンドにパスが通ってないらしい...
どうやら、
自分の場合だと、「C:\Users\Toshinobu\Desktop\soft_work\javascript_work\node_modules\.bin」まで移動しないと「Vue CLI」が実行できないらしい...これが「-g」オプション無しの結果なのか、単なる不具合なのかが判然としませんな...
「C:\Users\Toshinobu\Desktop\soft_work\javascript_work\package-lock.json」を見た感じ、「Vue.js」のバージョンは「2.6.14」になってるっぽい。
ただ、
また、これらのnpmで公開されているパッケージでは後ろにバージョンを指定できます。バージョンはメジャーバージョンだけ、マイナーバージョンまでなど、柔軟に指定でき、指定の中での最新版がインストールされます。
⇧ 上記サイト様によると、「npm install」時にインストールするパッケージのバージョンを指定できるらしいので、バージョンを指定したほうが良さ気ですね、「Vue CLI」のドキュメントには一言も書いてなかったけど...
まぁ、何はともあれ、これで、ようやく「Vue.js」が使えるようになったようなので、「Vue.js」のプロジェクトを作成しようと思うのですが、
WARNING
If you are on Windows using Git Bash with minTTY, the interactive prompts will not work. You must launch the command as winpty vue.cmd create hello-world. If you however want to still use the vue create hello-world syntax, you can alias the command by adding the following line to your ~/.bashrc file. alias vue='winpty vue.cmd' You will need to restart your Git Bash terminal session to pull in the updated bashrc file.
https://cli.vuejs.org/guide/creating-a-project.html#vue-create
⇧ やんごとなきWindowsへの除け者扱いは続くという...
ただ、今回、コマンドプロント使っちゃってるから、特に対応しなくても問題ないんかな、というか、「Git」とか必要なんかな？特に「Git」が必要とかって「Vue CLI」のドキュメントに書いてなかったと思うけど。
一応、「Git for Windows」は昔にインストールしてはあるけども。
そして、気になる「Vue.js 」プロジェクトのディレクトリ構成はどうすれば良いのかがよく分からんのだけど、「Vue.js」の「core principal」を謳ったビデオによると、
⇧ 上記のような構成になるらしいんだけど、そもそもビデオだと「vue init」を使ってて、「vue create」じゃないんかい！っていうツッコミを入れたくなるんだが...
あと、「vue create」コマンドのオプションを見てみても、
⇧ 作成されるプロジェクトをどこのディレクトリに配置するのかっていうオプションが見当たらないという...
上がってる「issue」によると、
⇧「-l」オプションあるよ、って言ってるんだけど、無いんですけど...
「vue --help」で確認しても、ディレクトリ指定できるなんてどこにも書いてないんだけど...なんか、公開されてないドキュメントとかあるんかいな...
そして、悲報...
Forehead slap. It will create the project in the current folder.
So you have to cd into the folder you want to create the project in and then do your vue create.
Never mentioned in the vue cli guide or the tutorial I am using so one of those many "we assume you already knew it" things that hang us up learning new things.
https://stackoverflow.com/questions/60840105/change-vue-cli-create-path-location-on-windows
⇧どうやら、「Vue.js」のプロジェクトを作りたいディレクトリに移動してから「vue create」コマンドを実行する必要がある、とのこと。
自分の場合（Windows 10 Homeで、「WSL 2（Windows Subsystem for Linux 2）」とかも特に使っていない環境で、「Vue CLI」を導入してます）、「C:\Users\Toshinobu\Desktop\soft_work\javascript_work\node_modules\.bin\vue」ってファイルが「Vue CLI」ということになるらしいので、
以下のように、「Vue.js」のプロジェクトを作成したいディレクトリに移動した後で（「Vue.js」のプロジェクトを本来はどこに作成すべきなのかは分かっていません...）、フルパスで「Vue CLI」コマンドを実施しました。
⇧「Vue.js」のプロジェクトが作成されたらしい。
指示にあるように、コマンドを実行すれば、「Vue.js」のサンプルが起動するらしいので、試してみます。
コマンドを実行すると、「Vue.js」のプロジェクトに内蔵されたサーバーが起動するらしく、
「ファイアウォール」で通信の許可を求められたら、「アクセスを許可する(A)」を選択で。
ブラウザで「http://localhost:8080/」にアクセスすると、作成した「Vue.js」のプロジェクトが表示されました。
サーバーを停止するには、サーバーのプロセスを動かしてるコマンドプロンプトで「Ctrl」キー＋「C」キーを押下すると、「バッチ ジョブを終了しますか（Y/N）?」と表示されるので、「Y」を入力して「Enter」キーを押下。
サーバーを停止した後で、ブラウザのリロードボタンを押下すると、
アクセスが遮断されることが確認できました。
ちなみに、作成された「Vue.js」のプロジェクトのディレクトリ構成は以下のようになっていました。
⇧「Vue.js」のプロジェクト用の「node_modules」ディレクトリが作成されてることから、「node_modules」ディレクトリはいろんな場所に作成されるっぽいですね、パスの問題が頻発しそうですな...
ブラウザに表示されたページの内容なんかは、「src」フォルダにあるものっぽい。
試しに「Visual Studio Code」でディレクトリ構造を確認してみると、
「main.js」で「App.vue」を読み込んでいて、更に「App.vue」が「/components/HelloWorld.vue」を読み込んでるっぽい。
「拡張子」が「.vue」のファイルは、
これら全ては Webpack や Browserify のビルドツールにより実現された .vue 拡張子の 単一ファイルコンポーネント で解決します。
⇧どうやら「Vue.js」独自のファイルということらしい。
「バージョン 2」のドキュメントを見ると、「Vue.js」は、
全ての Vue アプリケーション は、Vue 関数で新しい Vue インスタンスを作成することによって起動されます。
var vm = new Vue({
// オプション
})Vue のデザインは、MVVM パターンと厳密には関連が無いものの、部分的には影響を受けています。慣例として、 vm (ViewModel の略) を Vue インスタンスの変数名としてよく使います。
⇧「Vue インスタンス」なるものが必要らしく、
「Vue.js」が実行されるフローを見てみると、
⇧ 上図のような感じになっていて、
「vue create」コマンドは、おそらく「beforeCreate」と「created」の間（赤枠を勝手に追加してます）にある「init injections & reactivity」のとこで実施されるっていうことなんかな？（それぞれの登場人物が具体的に何を表してるのかの説明が無いのでサッパリ分かりませんが...）
ここで、「vue」コマンドのヘルプを確認する以下のコマンドを実行してみると、
[Vue.jsのプロジェクト用に用意したディレクトリ]\node_modules\.bin\vue --help
以下の結果が表示されましたと。
Usage: vue <command> [options] Options: -V, --version output the version number -h, --help output usage information Commands: create [options] <app-name> create a new project powered by vue-cli-service add [options] <plugin> [pluginOptions] install a plugin and invoke its generator in an already created project invoke [options] <plugin> [pluginOptions] invoke the generator of a plugin in an already created project inspect [options] [paths...] inspect the webpack config in a project with vue-cli-service serve [options] [entry] serve a .js or .vue file in development mode with zero config build [options] [entry] build a .js or .vue file in production mode with zero config ui [options] start and open the vue-cli ui init [options] <template> <app-name> generate a project from a remote template (legacy API, requires @vue/cli-init) config [options] [value] inspect and modify the config outdated [options] (experimental) check for outdated vue cli service / plugins upgrade [options] [plugin-name] (experimental) upgrade vue cli service / plugins migrate [options] [plugin-name] (experimental) run migrator for an already-installed cli plugin info print debugging information about your environment Run vue <command> --help for detailed usage of given command.
で、俄然、気になってくるのが、
- create [options] <app-name>
create a new project powered by vue-cli-service - init [options] <template> <app-name>
generate a project from a remote template (legacy API, requires @vue/cli-init)
「Vue.js」のプロジェクトを作成する方法が、2つあるやんというね...
説明を読んでも、そもそも「init」の説明にある「remote template」が何なのか分からんし、「create」の説明にある「vue-cli-service」が何なのかも不明というね...
「vue-cli-service」については、
Inside a Vue CLI project, @vue/cli-service installs a binary named vue-cli-service. You can access the binary directly as vue-cli-service in npm scripts, or as ./node_modules/.bin/vue-cli-service from the terminal.
https://cli.vuejs.org/guide/cli-service.html#using-the-binary
This is what you will see in the package.json of a project using the default preset:
https://cli.vuejs.org/guide/cli-service.html#using-the-binary
⇧ って説明によると、作成した「Vue.js」のプロジェクトの「./node_modules/.bin/vue-cli-service」に配置されてるらしい。
自分の場合は「C:\Users\Toshinobu\Desktop\soft_work\javascript_work\hello-world\node_modules\.bin\vue-cli-service」に配置されてました。
細かいことは分からんのですが、「vue create」は、『create a new project powered by vue-cli-service』って説明になってるので、「Vue.js」のプロジェクトの作成は「./node_modules/.bin/vue-cli-service」の機能で実施されるらしい。
じゃあ、「vue init」の「remote template」ってのは何なのか？
これについては、ドキュメントに情報が見当たらず、
A very common question from new Vue users, especially those who used Angular before, is “can I have templateURL?”. I have answered this so many times and I figure it’s better to write something about it.
In Angular, templateURL or ng-include allows the user to dynamically load a remote template file at runtime. This seems pretty convenient as a built-in feature, but let’s rethink what problem it solves.
⇧ 唯一、上記で1回だけ「remote template」って用語が出てくるんですが、JavaSciptフレームワークの「Angular」での話を例にしてるんですよね...
試しに「vue init」コマンドのヘルプを確認する以下のコマンドを実行してみると
[Vue.jsのプロジェクト用に用意したディレクトリ]\node_modules\.bin\vue init --help
以下の結果が表示されましたと。
Usage: init [options] <template> <app-name> generate a project from a remote template (legacy API, requires @vue/cli-init) Options: -c, --clone Use git clone when fetching remote template --offline Use cached template -h, --help output usage information
もう、これは推測の域を出ないのですが、上記のコマンドのヘルプにおける「template」が「Vue.js」のドキュメントの「Template Syntax」のことだと仮定して矛盾しないという前提とした場合、「vue init」は、
Template Syntax
Vue.js uses an HTML-based template syntax that allows you to declaratively bind the rendered DOM to the underlying Vue instance’s data. All Vue.js templates are valid HTML that can be parsed by spec-compliant browsers and HTML parsers.
⇧ リモート環境にある「HTML-based template syntax」を使って「Vue.js」のプロジェクトを作成するってことになるのではないかと。
なんか、
For Vue CLI v3, you can use vue create or vue ui to bootstrap an app. For Vue CLI v2, you use vue init.
⇧「Vue CLI」のバージョンによって、使い分けた方が良いらしい。
今回、「Vue CLI」は「バージョン 4系」を使ってるので、「vue create」で問題ないのかもしれない。
ちなみに、
⇧ 上記サイト様を参考に、今一度、「Vue.js」のプロジェクトの「Vue.js」のバージョンと「Vue CLI」のバージョンを確認してみる。
⇧「Vue.js」のバージョンは「vue@2.6.14」ということみたいです。
う～ん、「Vue.js」の情報を確認するのに時間がかかって、「Vue.js」のコーディングの学習が全く進まない...
というか、「vue create」してみたはいいものの、作成された「Vue.js」プロジェクトのどの場所に、どの「拡張子」のファイルを作ってコーディングしていけば良いのかサッパリ分からんですな...
2021年10月14日（木）22:45 追記：↓ここから
ちなみに、「PowerShell」とかだと、エラーになってしまったのだが...
コマンドプロンプトで動いて、「PowerShell」で動かないとか、よく分からんですな...
⇧ なんか、やたらと「-g」オプションを推してるんですよね...
とりあえずは、コマンドプロンプトを使っていくしか無さそうですかね...
本当、WindowsってWeb系と相性が悪い気がしてならんですな...
2021年10月14日（木）22:45 追記：↑ここまで
今回はこのへんで。
