NotePlan / NotePlan/plugins

[RFC] Using a package manager for plugins

オープン
#6 コメント 7 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

question
主要言語
JavaScript
スター
204
フォーク
82
平均マージ
22時間 27分
マージ済み PR(30日)
3

説明

While it's still early days for plugins in Noteplan, it might make sense to keep all the "blessed" plugins in this Github repo, but longer term, that'll start to get untenable. Specially when it comes to releases.

Using a package manager like NPM might make a lot of sense. Using registry.npm.org URLs it's fairly straightforward to search, get details and download packages that can go directly to the Plugins folder.

Here are the benefits to this approach:

  1. Third party packages can all follow a naming convention (e.g. noteplan-plugin-commandName) and publish them on NPM and they will become easily discoverable for users.
  2. NPM packages have versioning built-in and it will become easy for different plug-ins to be updated independently and for Noteplan to periodically check for updates easily by package name.
  3. Since NPM allows for an independent .npmignore file it'll become easy to ignore built files for GitHub and ignore source files for the NPM package. This way Noteplan doesn't have to download any unnecessary files.
  4. It should still be valid to use a Github URL to manually download plugins that aren't on NPM. (without all the extra feature though)

Possible downsides:

  1. Churn - NPM can be an additive feature so that the churn can be kept to a minimum.
  2. it slightly increases the barrier to entry, but it's really just an npm publish command for a plug-in author. For advanced plugins this would be a total win.

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

調査の方向性

この issue では、調査すべきファイル、テスト、エントリーポイントが示されていません。まず、プラグインの検出、ダウンロード、バージョニング、更新、GitHub フォールバックの要件を明確にし、その後、それらの要件を既存のプラグインインストールフローに対応付けてください。合意されたパッケージマネージャーの設計と、テスト可能な動作を含む実装計画ができれば完了です。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
javascript
領域
tooling
issue の種類
機能追加
難易度
5/5
見積もり時間
1週間以上
活発さ
停滞
明瞭さ
説明が足りない
初心者へのやさしさ
20/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。