Luma

https://github.com/aspida/aspida/pull/748 上記と似ていますね。 以下、メンバーと話して更に検討したうえでの現在の考えです。 @aspida/axios と frourio-express が本来その責任範囲外であるような `[]` 付加・取り外しをする、axios/expressデフォルト動作を抑えていないのが修正されるべきで、querystring同等の動作をさせたい場合は個別のプロジェクトで対処するのが良いではないかというふうに考えています。 `query: {id: string[]}` で `id[]=...` が勝手に飛んでいた @aspida/axios を修正して、もしほしいなら、 `query: { 'id[]' : string[]}` と書かなければいけないようにするほうが良いと思っています。

https://github.com/aspida/aspida/pull/687 これと競合しそう。どっちがいいか。上記PRのほうがいいかもしれない。

svelte-kit についてなんですが、ちょっと現段階ではとりあえず動くものというのもなかなか難しそうな気がします… ## svelte-kit の仕組み `npx snowpack dev` と `npx svelte-kit dev` でだいぶ違う。現状 private に開発されているので実験とビルドされたものに対してデバッグでわかったことは、snowpack を裏で動かして、手前側で svelte-kit 独自のサーバーを動かして、import 解決をsvelte-kit 側で独自にやる、という感じです。 ## 問題点 シンプルにバグがあると思います。svelte-kit に。それに対し issue も PR もできないのでなおさら厳しいかもです。まあ、開発中なので仕方ないですね…。 - svelte...

選択肢にする予定

docker/docker-compose を利用してセットアップ、みたいなチェックボックス作っておくのは、かなりありだなあと思ってます。DBなどだけであると。

api などは https://github.com/violet-ts/violet/blob/main/docker/prod/api/Dockerfile を書いたりしましたが幅が広すぎるので、まず最終形決めてやっていきたいところですね。これは容量結構気にしてますが、ここは容量そんなに気にせず安定側で良いと思います 例えば、…なんだろ。 docker-compose 入った環境で docker-compose up -d したらすぐ動かせるというのは一つ候補かな。

https://github.com/LumaKernel/coc-prettier_fork_joe/tree/luma [compare to this PR](https://github.com/joemckenney/coc-prettier/compare/joe/update-prettier...LumaKernel:coc-prettier_fork_joe:luma?expand=1) (treat my changes under CC0) I fixed this a little (dynamic import problem, fix trailingComma default in package.json), and it's running well in my project...

I guess he concerns backward-compatibility. We have another way, just publishing coc-prettier3