misaki-studio-npm contains the packaging shape used to turn exported Misaki Studio modules into installable package entry points.
Current status: unfinished for general use. Do not present the public repository as a neutral clone-and-publish starter. Its current main branch contains package identity and export maps generated for one project, has no src/ directory until a project is exported, and its webpack configuration references swc-loader without declaring it in package.json.
The repository is intended to:
discover TypeScript/TSX files recursively under src/;
build each discovered file as its own package entry point;
externalize React, React DOM, Next, and next/router;
expose generated modules through package.json exports and typesVersions after those maps have been generated for the current project;
publish with npm publish.
That is a useful direction, but the checked-in public repository is an example output state rather than a blank reusable contract. Its current configuration does not yet prove a valid package can be built and consumed.
Verified from public main on 2026-09-09:
The package name is a specific @misaki-studio/<project-uuid> value.
The version is a previously generated calendar-like release value.
exports and typesVersions list paths from that example project.
misaki-studio-internal is pinned to 0.1.52.
React >=18.2.0, React DOM >=18.2.0, and Next >=15.5.4 are peer dependencies.
The repository has no README and no neutral source tree.
Webpack names emitted JavaScript files as [name].js, while the generated exports map points CommonJS and ESM consumers to .cjs.js and .ejs.js filenames. Those paths do not currently match.
webpack.config.js imports swc-loader, but package.json does not declare it.
A declaration-plugin package is declared, but the current webpack configuration does not register that plugin. Do not assume the build emits the .d.ts files named by types or typesVersions.
.npmrc contains example placeholders and is expected to be rewritten by Misaki Studio's package-publication workflow; it must never contain a committed real token.
See the current public package.json and webpack.config.js before acting on these details.
Publishing the current clone without review could use another project's package name, version, entry points, or registry configuration. Before a general workflow can be approved, the starter needs:
Neutral package identity and empty generated maps.
A documented src/ and asset-output contract.
Every webpack loader/plugin declared and a clean installation/build test.
Verified filenames that match the package exports map for both import and require, or a deliberately supported subset.
A registry setup that reads credentials from the environment or a secure user configuration.
A tested example consumer that installs the packed tarball and imports at least one component subpath.
Until those checks pass, use Misaki Studio's dedicated Publish NPM workflow only with its own verified guide, or adapt the packaging model in a repository you control.
Coverage: Partial MCP.
An agent can inspect generated code, configure a local export target, and write project output to folders. That does not prove the package shell builds, that its exports map matches the output, or that publishing credentials and registry are safe.
Use a planning prompt first:
Inspect this npm boilerplate without changing it. Compare its package name, version, scripts, declared loaders, exports map, types map, peer dependencies, registry placeholders, and current source tree with my Misaki Studio project. Report every project-specific or unresolved item. Do not install, export, pack, or publish.
Before any registry action, require a local npm pack plus a clean consumer-install/import test. Package publication is an external and normally irreversible versioned action; it needs explicit approval after the tarball contents and destination are known.