Package command copies publishConfig.directory into the generated package.json

[boyeln]

Describe the problem

Referencing svelte-kit package generated packages through the workspace protocol of pnpm doesn't work out of the box. Most monorepo tools (pnpm included) will normally just symlink the root/source directory when you use a workspace version (like workspace:*). Since svelte-kit package outputs a new directory structure with its own package.json file, that doesn't work out of the box. You can however use a new feature (see this issue) in pnpm that allows you to specify the directory of the package (containing a new package.json) through the publishConfig.directory. This works great, and solves almost all of the problems. However, the package command copies the publishConfig.directory setting over to the new generated package.json file. This can cause a lot of issues, since that directory does not exist.

Describe the proposed solution

I suggest just removing the publishConfig.directory key if it exist from the generated package.json file, just like you already do for the script tag. I believe something like delete pkg.publishConfig?.directory close to where you delete the script key would suffice. However, it might be cases where this is not the desired behavior.

Alternatives considered

It does not seem to cause immediate problems for pnpm at least, since it only looks at the publishConfig.directory key once for the root/source directory, and not recursively. So it might be fine to keep it as is. But to me having the publishConfig.directory inside the generated package.json doesn't make sense, and I can imagine several cases where it would be troublesome.

Importance

nice to have

Additional Information

No response

[bertybot]

Fixing this would help me out a ton. Working with Sveltekit packages in monorepos right now is annoying.

[Tal500]

I'm not against this suggestion, but I do wonder, however - why do you need to run SvelteKit packaging on monorepos?

You may just import the path of the Svelte files to your other projects.

[boyeln]

@Tal500 You can just import paths, but then you'll not use the library the same way others use it when it's distributed. The monorepos I work with are usually one application and a bunch of distributed libraries owned and maintained by the app, but used by other apps as well. Then it's nice that using "workspace:*" in the monorepo that owns a package provides the same API as when external apps/packages imports it using a fixed version.

[Tal500]

@Tal500 You can just import paths, but then you'll not use the library the same way others use it when it's distributed. The monorepos I work with are usually one application and a bunch of distributed libraries owned and maintained by the app, but used by other apps as well. Then it's nice that using "workspace:*" in the monorepo that owns a package provides the same API as when external apps/packages imports it using a fixed version.

As a temporary/alternative solution to your problem, you can use path aliasing in Vite.
Just as SvelteKit has $lib to be path aliased to your lib dir, you can also define Vite alias in the configuration for the library name to also reference the the lib dir.

See for example what I did there:
https://github.com/Tal500/svelte-file-dropzone/blob/b01b64554395343721a52378e286f0193664695f/vite.config.js#L13
And then I could just do import {...} from 'svelte-file-dropzone' in the example, so the viewer will be fooled to think it is actually get loaded like a regular NPM library.

[boyeln]

@Tal500 Thanks for the example, but the alias and resolution of packages is not the problem. The problem is that the svelte-kit package command copies settings over to the generated package that's specific to the original/root/source package.json file. These settings causes trouble when you later try to publish or do things with the generated package.
More over, I think hard coding resolutions is a bad pattern. It's better to get the package manager/monorepo tooling to do this for you, as that's what they are designed to do. Having dependencies that's not listed in package.json or inside node_modules could also break a lot of tools that expects all dependencies to be precent there (security scanning, license scanning, testing tools etc).