進捗を作るvscode 拡張

• generaterを使ってひな形作成

npm generator
yo

• 作りたい機能を実現するためのAPiを探す
  公式APIリファレンスを参照(だいたい全部書いてる)
• package.jsonにマニフェストを記述する
  説明等、拡張が有効化されるイベントやコマンドを定義する
• publish

npm vsce

リファレンス参照

公開までは簡単

tsconfig.jsonを完全に理解する

whatis tsconfig.json

typescriptのコンパイルオプションを置くためのもの

コンパイル対象指定

• files
• excludes
• include

tscでコンパイルする対象を指定する(webpackで対象指定すると不要？) filesは個別に指定,include/excludeは個別に指定する

project分割 references/extends home/tsconfig-base.json:基底クラス src/tsconfig.json:本番ファイル、これをtest/のtsconfigに継承させる

IDE typeacquisition import字に型ファイルをIDEが自動取得するか compileOnSave tsconfigの変更時にビルドし直すか

target JSノバージョン module import/export方式

commonjs require/exports

es6 import export

Ionicの勧め

Angular(最近Reactも )をベースにHTML５アプリの開発に特化して作られたJavaScriptフレームワーク. webアプリからスマホアプリまで開発できる。

denoについて,Nodejsとの違い

Nodejsみたいなもの(改訂版)

requireとimportが違う

Nodeのimportは複雑、未実装、ブラウザ日互換性 denoはimportしかない npmは使えないけれど、ブラウザ向けのモジュールをそのまま使える commonjs <->mjsの相互運用を考えなくて良い npm Incへの依存がない

Security

DenoはV8ベーす V8はサンドボックス環境になっている、中のプログラムが容易に外部のプログラムやファイルにアクセスできない仕組み NodeはOS昨日にアクセスできるNative拡張を入れた→サンドボックスがなくなる ファイルアクセスの際に全て許可制 パッケージごとに対しての権限は？ このファイルに対してこのパーミッションを与えるみたいなの？

実装の違い

Node vanilla.js c++
Deno Rust Typescript(優勝)

言語のカバー範囲への思想

Node
スモールコアという考え方：Node自体は最小限の機能しか実装しない,他の全ての機能はnpmmに以上 メリット

• 誰でも標準機能を作れる→標準機能の進化ex)axious→ky jslint→eslint
  悪い点
• 標準機能の乱立
• 依存関係の沼

Denoの標準ライブラリはリッチ、Go言語の標準ライブラリのカバー範囲のカバーがGoal

フロントエンドの組織

フロントエンドエンジニアのやることが増えすぎている,領域が広がり式ている

→フロントエンドエンジニアという言葉で済ませていいのか？ デザインとバックエンドの中間 足回り係が軽視されてしまう →真綿で首を締められていくような感じ

Optional Chainingについて

what is optional chaining

TS3.7で導入 Objectのプロパティ値参照で、プロパティの存在チェックを明示的に書かなくても処理してくれる仕組み。 現在Stage 3 TYpeScriptでは3.7で先行的に導入

how to use

存在しないような可能性があるプロパティにアクセスする APIの返却結果など、どのプロパティがRequiredであるかについて保証がないアビイについて操作 nullやundefinedのチェックを書く必要がなくて、より簡潔なコードがかける