chore: remove the plugin and customize packages superseded by cli-kintone

[nameless-mc]

Why

@kintone/create-plugin, @kintone/customize-uploader, @kintone/plugin-packer and @kintone/plugin-uploader are replaced by the plugin and customize commands of cli-kintone, which ships a migration guide.

These packages will be marked as deprecated on the npm registry. Keeping their sources here would leave them in CI, in the dependency update rotation, and — more importantly — in the release path: a dependency update alone is enough for release-please to bump one of them and publish a version that carries no deprecation. Removing them closes that path. @kintone/data-loader was retired the same way in #1804.

What

Removes the four package directories and every reference to them left in the repository:

• release-please-config.json and .release-please-manifest.json: the four entries. This is what stops further releases; the packages also leave the pnpm workspace with their directories.
• renovate.json5: the npm.fileMatch for the create-plugin template and the custom manager that tracked the @kintone/plugin-manifest-validator version embedded in packages/create-plugin/src/manifest.ts, together with the package rule that only applied to that manager.
• .github/workflows/release.yml: the four npmjs /access links in the header comment.
• .github/labeler-config.yml and both issue templates: the per-package labels and the package options.
• README.md and packages/tsconfig.json: the package table rows and the TypeScript project references.
• packages/webpack-plugin-kintone-plugin/tsconfig.json: the project reference to ../plugin-packer. The package already depends on @kintone/cli instead, and its package.json declares no dependency on plugin-packer; the only mention left in its sources is an attribution comment in src/plugin.ts, which is not a build dependency. The project reference was stale.
• packages/plugin-manifest-validator/README.md: its Node.js badge read engines.node from create-plugin/package.json, so it now reads the value from its own package.json. The line naming plugin-packer as the consumer now names cli-kintone, which depends on this package.

packages/dts-gen/package.json gains a process devDependency. dts-gen/webpack.config.js provides process/browser through ProvidePlugin but never declared the package; it resolved only because plugin-packer declared process@0.11.10 and pnpm hoisted it. Without the declaration, build:integration fails with Can't resolve 'process/browser'.

pnpm-lock.yaml is regenerated.

Follow-ups, not included here:

• Run npm deprecate for the four packages (all versions) with a message pointing at the migration guide. Trusted publishing cannot do it: the OIDC credential covers npm publish only.
• Remove the trusted publisher configuration of the four packages on npmjs.com.

How to test

• pnpm install --frozen-lockfile succeeds, then pnpm build and pnpm test pass on the root directory. The TypeScript project references are the part worth watching: packages/tsconfig.json and packages/webpack-plugin-kintone-plugin/tsconfig.json both pointed at removed packages.
• prettier --check passes for the changed JSON, Markdown and YAML files.
• Renovate and the labeler run against the changed configuration without referring to the removed paths.

Checklist

• Read CONTRIBUTING.md
• Updated documentation if it is required.
• Added tests if it is required.
• Passed pnpm lint and pnpm test on the root directory.

[shabaraba]

この行が repo 内で唯一の process の宣言であり、packages/dts-gen が宣言なしでこれに依存している。plugin-packer を削除すると pnpm build が失敗する。

packages/dts-gen/webpack.config.js は ProvidePlugin({ process: "process/browser" }) を宣言するが、packages/dts-gen/package.json は process を dependencies にも devDependencies にも書いていない。pnpm の hoist store が解決を成立させていた。lockfile から process@0.11.10 が落ちると、@kintone/dts-gen の postbuild → build:integration が Module not found: Error: Can't resolve 'process/browser' で失敗する。

確認した内容:

• このブランチで pnpm install --frozen-lockfile は成功し、pnpm build は packages/dts-gen の解決エラー 6 件で失敗する
• origin/main では同じ 2 コマンドが成功する（exit 0）。ローカル環境の問題ではなく、この PR による regression である
• pnpm -r --parallel --no-bail run postbuild で失敗するのは dts-gen のみ。pnpm lint と pnpm test は通る

.github/workflows/test.yml（Node 20/22/24 × ubuntu/windows/macos の 9 ジョブ）と .github/workflows/lint.yml はどちらも pnpm build を実行する。CI が動けば必ず失敗する。現在 checks が出ていないのは draft のためである。

対応: packages/dts-gen/package.json の devDependencies に process を追加し、lockfile を再生成する。同ファイルで assert を resolve.fallback 向けに宣言しているのと同じ形になる。integration test の bundle が polyfill を必要としないなら、ProvidePlugin の項目を削除する選択肢もある。

[nameless-mc]

Thanks — confirmed and fixed in 25fe088.

packages/dts-gen/package.json now declares process@0.11.10 in devDependencies, next to the assert entry that backs resolve.fallback. I kept the ProvidePlugin entry: the integration bundle still needs the polyfill.

Verified on this branch: pnpm install --frozen-lockfile and pnpm build both succeed, and the lockfile diff is limited to the process entry.