JSON for Humans View the Project on GitHub json5/json5 JSON5 – JSON for Humans JSON5 is an extension to the popular JSON file format that aims to be easier to write and maintain by hand (e.g. for config files). It is not intended to be used for machine-to-machine communication. (Keep using JSON or other file formats for that. 🙂) JSON5 was started in 2012, and as of 2022, now gets >65M downloads/w
重い腰を上げて FlatConfig 対応をした ESLint が新しい設定形式として FlatConfig を導入してから随分と経ち、最新バージョンの v9 では FlatConfig がデフォルトになりました。一方で利用者の多い plugin でもなかなか対応が進まず、周りでは思ったよりも FlatConfig への移行が進んでいない印象を受けます。 とはいえ次のバージョンである v10 では FlatConfig しかサポートしないことが予定されており、今まで移行を見送ってきた方も「さすがにそろそろ移行するか...」と思っているのではないでしょうか。自身の所属チームで管理している ESLint の rule セット : @cybozu/eslint-config でも遅ればせながら FlatConfig 対応を進めています。（現在はアルファ版で提供中です） そんな @cybozu/e
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>name</key> <string>Swallow</string> <key>job</key> <dict> <key>title</key> <string>Sr. Nest Maker</string> <key>company</key> <string>Nests R Us</string> <key>yearsOfExperience</key> <integer>2</integer> </dict> </dict> </pl
written by Ruud van Asseldonk published 11 January, 2023 For a data format, yaml is extremely complicated. It aims to be a human-friendly format, but in striving for that it introduces so much complexity, that I would argue it achieves the opposite result. Yaml is full of footguns and its friendliness is deceptive. In this post I want to demonstrate this through an example. This post is a rant, an
[ { "name": "An object that takes many lines to describe" }, { "name": "Many lines of definition" }, { "name": "Multi-line object" } ] のような場合、末尾の要素を末尾以外に移動したり、末尾に要素を追加したりすると「ここにカンマがあると文法エラーです」とか「ここにはカンマが必要です」とかいう文法エラーに見舞われる。というわけで、順序変更や末尾付近で追加削除するときにストレスを感じる。 これがケツカンマ問題である。 ケツカンマ問題が問題なのは、行末にコンマが必要な場所と行末のコンマが禁止の場所が両方あるからなので 全部コンマありなら問題ないような文法 全部コンマなしなら問題ないような文法 のいずれかなら人間としては楽になる。 具体的には、 最後の要素の後にコンマ
YAMLは「便利なJSON」として使われることが多い一方、その複雑性から落とし穴も多く、しばしば批判の対象になります。 なぜYAMLはそこまで複雑なのでしょうか? その背景のひとつは、本来のYAMLがJSONとは大きく異なる目的意識で作られているからです。 本稿ではYAML specに従う形でYAMLのコンセプトを解説することを目指します。残念ながら、ここに書かれているYAMLの思想は実際には実用されているとは言い難いですし、これらの背景を理解しても「YAMLは複雑だ」という事実がひっくり返ることはないでしょう。それでも、YAMLの複雑さの源泉を体系的に理解し、YAMLとほどほどの距離感で付き合う助けにはなるのではないかと思います。 この記事ではこういう話をしますYAMLはJSONとは独立に、異なる目的で生まれた野心的な仕様であるアンカーやタグなどの強力な構文は、これらの目的を満たすために
皆さんこんにちは。株式会社バベルでエンジニアをしている uhyo です。バベルが提供しているaileadというプロダクトでは TypeScript が多く使われており、ESLint も活用されています。この記事では、ailead のコードベースにおいて ESLint の新しい設定フォーマットであるFlat Config (eslint.config.js)を導入した事例を紹介します。 Flat Config とは？ Flat Config については、ESlint 公式ブログでも詳しく説明されています。 ファイル名がeslint.config.js固定であり、必ず JavaScript で書かなければいけないのが特徴です。新しいフォーマットでは、従来の設定ファイル（.eslintrc{.yml,.json,.js}）で辛かった部分が解消されています。特に、設定内容の解決にあたって ESLi
はじめに ESLint v8.21.0のリリースでこれまでとは異なるconfigシステム（flat config）が持ち込まれた。 以下の通り、新しいconfigシステムへの一歩というように言及があり、ESLintを利用する上で無視できない影響を受ける変更となりそうなので、どのようなものか確認しておきたい。 We took a big step toward ESLint’s new config system! The new FlatESLint class is now merged. Its API is not yet stable, and not all features are implemented yet, but it is accessible via the Node.js API for early testing. See RFC9 for the origi
最近、$HOME/.config に設定ファイルを配置するツールが多くて、これは一体どういうことなんだということを思っていました。git とか peco とかですかね。 たぶん、ls -al ~ とかするとファイル数おおくて収拾つかなくなることに対する問題意識からそういう風になっているんだと思うんですが、ひょんなことから、これはどうも XDG Base Directory という仕様によって決められているということを知りました。 仕様自体はここにあります。 XDG Base Directory Specification この仕様上、設定ファイルの格納ディレクトリは、$XDG_CONFIG_HOME という環境変数に定義することになっていて、これが空か未定義の場合に $HOME/.config が使われることになっています。 たとえば peco の場合はこのあたりで実現されてる。 http
いろいろな JavaScript 系ライブラリの設定ファイルで型の補完が効くようにするための JSDoc アノテーションまとめです。VSCode で確認しています。 リンクのついていないものは自分で型定義を探したものなので間違っている場合はコメントいただけると助かります。 他のライブラリの情報もコメント大歓迎です！
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 追記1: コメントでの指摘を受け、gvmに関する記述を削除 この記事は、日経ソフトウェア 2013年 06月号 04/24発売 のステマ記事です。 6月号に、@keiji_ariyama(前座部分担当) と 僕(Gradle概要担当) と @sys1yagi(Android対応部分担当) という分担でGradle入門的な記事を書きました。 ですが、僕の目的としてはトップゲート社員への布教を主目的と考えて書いたため、本来要求されている分量を(わざと)大幅にオーバーして書いていました。雑誌に掲載されなかった溢れ分をネットで公開して良いか打診
これは、 G* Advent Calendarの15日目の記事です。 昨日は @int128 さんの Gradle Slashプラグインをリリースしました #gadvent でした。 明日は @tyama さんです。 #はじめに Gradle 便利ですよね。便利すぎて Ant や Maven には戻れないです。 なにが良いって、設定ファイルである build.gradle の記述量が、 Ant の build.xml や Maven の pom.xml と比べると非常に少なくて済むのが良いです。 build.gradle は、設定ファイルと言いつつも、その実体は Groovy で書かれたスクリプトファイルです。 Gradle は、 Groovy の持つメタプログラミング機能や省略記法などを利用して、設定を簡潔に記述できるようになっています。 これはメリットなのですが、一方で Groovy
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
