Question regarding dependency limits and bundle size for Community Plugin submission

[Yuichi-Aragi]

Hi everyone,

I’m currently developing a comprehensive plugin manager called Canary Edge. It’s designed to handle granular version control, lazy loading, discovering, managing, and health scoring for other plugins.

Because of the scope of the project (UI components, GitHub API integration, and Markdown parsing), my package.json has grown quite significantly (around 40+ dependencies including React 19, TanStack Query, and the Unified/Remark ecosystem).

Before I get too deep into the final stages of development, I wanted to ask the community and the reviewers:

1. Are there any hard or soft limits on the number of dependencies a plugin can have?
2. Review Process: Does a large dependency list trigger a more manual/strict security audit during the Community Store review?
3. Performance: While I am using esbuild for tree-shaking and minification, are there specific bundle size thresholds that the team looks out for regarding startup performance?

For context, here is my current package.json:

{
  "name": "canary-edge",
  "version": "1.0.0-beta.23",
  "description": "An opinionated, comprehensive plugin manager. Discover, install, and manage community and beta plugins with granular version control, lazy loading, and health scoring.",
  "author": "Yuichi-Aragi",
  "license": "MIT",
  "keywords": [
    "obsidian-md",
    "obsidian-plugin"
  ],
  "main": "main.js",
  "scripts": {
    "build": "node esbuild.config.mjs",
    "typecheck": "tsc --noEmit",
    "lint": "eslint src",
    "release": "node version-manager.mjs"
  },
  "dependencies": {
    "@floating-ui/react": "0.27.17",
    "@gsap/react": "2.1.2",
    "@hookform/resolvers": "5.2.2",
    "@octokit/request-error": "7.1.0",
    "@octokit/rest": "22.0.1",
    "@radix-ui/react-dropdown-menu": "2.1.16",
    "@radix-ui/react-context-menu": "2.2.16",
    "@tanstack/react-query": "5.90.19",
    "ahooks": "3.9.6",
    "class-variance-authority": "0.7.1",
    "clsx": "2.1.1",
    "es-toolkit": "1.44.0",
    "gsap": "3.14.2",
    "lru-cache": "11.2.5",
    "mutative": "1.3.0",
    "neverthrow": "8.2.0",
    "p-queue": "9.1.0",
    "react": "19.2.3",
    "react-dom": "19.2.3",
    "react-error-boundary": "6.1.0",
    "react-hook-form": "7.71.1",
    "interactjs": "1.10.27",
    "react-use": "17.6.0",
    "react-virtuoso": "4.18.1",
    "react-photo-view": "1.2.7",
    "reflect-metadata": "0.2.2",
    "rehype-parse": "9.0.1",
    "rehype-stringify": "10.0.1",
    "remark-gfm": "4.0.1",
    "remark-parse": "11.0.0",
    "remark-stringify": "11.0.0",
    "safe-stable-stringify": "2.5.0",
    "serialize-error": "13.0.1",
    "sonner": "2.0.7",
    "tiny-invariant": "1.3.3",
    "ts-pattern": "5.9.0",
    "tslog": "4.10.2",
    "tsyringe": "4.10.0",
    "unified": "11.0.5",
    "unist-util-visit": "5.1.0",
    "uuid": "13.0.0",
    "valibot": "1.2.0",
    "zustand": "5.0.10",
    "@visx/group": "3.12.0",
    "@visx/shape": "3.12.0",
    "@visx/text": "3.12.0",
    "@visx/scale": "3.12.0",
    "@visx/responsive": "3.12.0"
  },
  "devDependencies": {
    "@eslint/compat": "2.0.2",
    "@eslint/js": "10.0.1",
    "@types/hast": "3.0.4",
    "@types/mdast": "4.0.4",
    "@types/node": "25.2.3",
    "@types/react": "19.2.14",
    "@types/react-dom": "19.2.3",
    "@types/semver": "7.7.1",
    "esbuild": "0.27.3",
    "esbuild-sass-plugin": "3.6.0",
    "eslint": "10.0.0",
    "eslint-plugin-react": "7.37.5",
    "eslint-plugin-react-hooks": "7.0.1",
    "globals": "17.3.0",
    "obsidian": "1.12.0",
    "sass": "1.97.3",
    "semver": "7.7.4",
    "tslib": "2.8.1",
    "typescript": "5.9.3",
    "typescript-eslint": "8.55.0"
  },
  "packageManager": "[email protected]",
  "engines": {
    "node": ">=20.19.6",
    "pnpm": ">=10.29.1"
  },
  "pnpm": {
    "onlyBuiltDependencies": [
      "esbuild"
    ]
  }
}

I’m aiming for a very polished, “IDE-like” experience, which explains the UI libraries (Radix, GSAP, Visx), but I want to ensure I’m staying within the best practices of the Obsidian ecosystem.

Thanks in advance for any guidance!

[joethei]

We currently do not allow for third-party plugin stores.
Sorry about that.

[Yuichi-Aragi]

Hi joethei,

I appreciate the response. I completely understand the team’s perspective regarding security and the desire to maintain a centralized, safe experience for the average user. Security is paramount in an ecosystem as extensible as Obsidian.

However, I would like to ask the team to reconsider this stance for a few reasons:

1. This is for Power Users: Canary Edge is specifically designed as an alternative for power users who find the official marketplace too limiting for their specific workflows. I am not trying to replace the official store for the general public, but rather provide a high-end, “IDE-grade” UX for those who want granular version control and health metrics.

2. It is a Community Contribution, not a Product: I am not charging for this or trying to “gatekeep” content. My goal is simply to provide a new level of UI/UX sophistication to the community. If the community plugin ecosystem blocks tools that innovate on how we manage our environments, it feels like we are limiting the very extensibility that makes Obsidian great.

3. I am not in a rush: I recognize the immense burden on the review team right now. I am perfectly willing to wait as long as necessary—even a year or more—for a manual review to ensure the code meets your security standards.

4. Transparency and Risk: I am ready to explicitly state in the README and within the plugin’s UI exactly who this tool is for and what the inherent risks of using a third-party manager are. I want users to be fully informed.

5. Non-Intrusive: To be clear, my plugin does not modify or interfere with the existing official marketplace. It exists alongside it as a separate utility.

I believe there is room in the ecosystem for “pro” tools that cater to the advanced segment of the user base. I’d love to find a middle ground where this can be reviewed and eventually included for those who need it.

Best,
Yuichi-Aragi

[joethei]

The decision stands, we will not accept any third party plugin stores inside the community plugins.

[Yuichi-Aragi]

I understand. I’ll be moving forward with an independent release on GitHub and will no longer seek a spot in the Community Store. Thanks for the feedback.