azu
- TODO: Chrome Extension should be updated before merging this - It is necessary to consider whether there are other problems caused by different update timings.
@dependabot merge 11/19/2024, 12:26:40 PM "JXA-userland/JXA" ***@***.***>
@dependabot merge 11/20/2024, 12:26:22 AM "JXA-userland/JXA" ***@***.***>
@Itsuki54 さんにやってもらう
`linter.lintText(text, filePath)` `filePath` is used for detecting what file type. If you want to lint text as Markdown, please use `linter.lintText(text, "dummy.md")`. If you want to lint text as Text,...
[Release ES2025 Candidate March 31st 2025 · tc39/ecma262](https://github.com/tc39/ecma262/releases/tag/es2025-candidate-2025-03-31) ES2025のCandidateもリリースされた - https://github.com/tc39/ecma262/pull/3552
# [`RegExp.escape`](https://github.com/tc39/proposal-regex-escaping) `RegExp.escape` が追加される > 次のコードでは、RegExpコンストラクタで変数spaceCountの数だけ連続するホワイトスペースにマッチする正規表現オブジェクトを作成しています。 注意点として、\（バックスラッシュ）自体が、文字列中ではエスケープ文字であることに注意してください。 そのため、RegExpコンストラクタの引数のパターン文字列では、バックスラッシュからはじまる特殊文字は\（バックスラッシュ）自体をエスケープする必要があります。 > [正規表現リテラルとRegExpコンストラクタの違い ](https://jsprimer.net/basic/string/#difference-regexp-literal-regexp-constructor) 必要とは言い切れないけど、ここで`RegExp.escape`の解説を入れるのは自然な気がする。 ただ、サンプルコードはescapeを必要にしてないので、やる場合は1つサンプルコードを書くのが良い気がする。 String.replaceAllでまさに実用的なユースケースがあるので、ここで使う例を出すと良さそう 具体的なユースケースは、変数で受け取った値をreplace all したいというケースかもしれない。 けど、replaceの時代には必要だったけど、今はreplaceAllではんぶんぐらいはいいかもしれない… ``` // replaceAllメソッドにも正規表現を渡せるが、この場合はエスケープが必要となるためreplaceと同じ console.log(str.replaceAll(/\?/g, "!")); // => "!!!" ``` ## 結論 -...
# [Float16Array](https://github.com/tc39/proposal-float16array) Float16Arrayが追加された。 - https://ics.media/entry/250408/ ArrayBuffer自体がそんな扱ってないものなのでやらないで良さそう ## 結論 - やらない
# [Promise.try](https://github.com/tc39/proposal-promise-try) `new Promise((resolve) => resolve(func()));` のイディオムが不要になる - [Promise.try() - JavaScript | MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/try) `Promise.try(func, arg1, arg2);` とかもできる。 [util.promisify(original)](https://nodejs.org/api/util.html#utilpromisifyoriginal)も出てきてないし、あんまり実用のユースケースがない感じがする どちらかというとPromise本向け - https://github.com/azu/promises-book/issues/283 ## 結論 - やらない
# [Iterator Helpers](https://github.com/tc39/proposal-iterator-helpers?tab=readme-ov-file) Iteratorを便利するもの。 Arrayからも `Array.prototype.values()` とかでIteratorを作れる。 これをやる場合は、https://jsprimer.net/basic/array/ の後に Generator/Iterator/Iterable の章を足すぐらいの気持ちでやった方が良い気がする。 無限リスト自体は、今のLLMの[server-sent events](https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events)でやってるような仕組みがかなり見かけるようになったので、実ユースケースは増えていそうな気がする。 ただ、現在は同期的なIteratoのみで、[Async Iterator Helpers](https://github.com/tc39/proposal-async-iterator-helpers)はまだStage 2だった。 Generatorを入れてなかった経緯 meetingsディレクトリにある会議の議事録を検索したところ、Generatorについていくつか興味深い議論が見つかりました。これらの情報から、JavaScriptプライマーの著者たちがGeneratorを本に含めなかった理由を整理してみます。 Generatorを含めなかった主な理由 会議の議事録から見つかった情報をまとめると、以下の理由でGeneratorを本の内容から省いたことがわかります： 複雑性: 2016-09-09の会議で「Generatorは複雑」と明確に述べられています。 初学者向けの内容を目指していたため、複雑な概念は避けたかったようです。 言語機能の削減: 「Generatorを省くと、yield, function *を無くすことができる」と述べられており、説明すべき言語機能を絞りたかった意図がうかがえます。 必要性の判断: 「Generator自体はいらないけど、iterableはspread...