Convoluted way of using @svelte/package
inside a monorepo
#11866
Labels
pkg:svelte-package
Issues related to svelte-package
@svelte/package
inside a monorepo
#11866
Describe the problem
π Hi, how are you? π I hope everything is all right.
We are developing a monorepo with pnpm workspaces and Turbo repo.
This is our monorepo file structure
NOTE:
apps/server
andpackages/svelte-ui
both are SvelteKit apps.We have several goals with
@fun-with-monorepo/svelte-ui
packagestep inside this package and let our main app in
./apps/server
compile the.svelte
and.ts
files in this package. Way faster, feels like developingin the app.
another SveltKit app.
using their packaging npm module called @svelte/package.
So as you can points (1) and (2) are about our dev experience as monorepo
developers. And points (3) and (4) are about shipping this package as an npmjs
UI library other people can use.
The problem?
Right, the problem. Here starts the funny part. Before 2023
svelte-package
wasmodifing your
package.json
and Svelte maintainers felt (I think) that was not agood idea (and I agree). Rich Harris can explain better than I do. But long story short we want 2 different things while we're developing this package inside the monorepo and when we build it for others to use.
The difference resides in the
package.json
exports
field. For comparisonhere is what we want in dev and production build:
Development
Production
As you can see in dev we point directly to the
.src/lib
source code because weknow our Storybook or our other SveltKit app (the main app) in
./apps/server
are doingthe work of transpiling all the
*.{ts,svelte}
files. Nice!On the other hand on production we want to point
exports
field inpackage.json
to./dist
folder that was produced bysvelte-package
.Describe the proposed solution
No solution, at least nothing I can think that can be applied. But I'm here to listen to alternatives. : )
Alternatives considered
Weeell, as always with code is all about trade-offs. We would't had this problem
if this package was not a
SvelteKit
app and we didn't usesvelte-package
. Wecould do our own rollup plugin and ship it this way. But I think that by staying with the official
way we're more aligned with svelte ecosystem.
Sooo, what's the solution?
The solution is to put in git the development version of exports pointing to
./src/lib
so this way dev experience is fantastic. And when we do the building we modify on runtime thepackage.json
with aprebuid
script that you can see in this same folder. This script is used in thescripts
field in thepackage.json
like this:All is perfect for one little thing. After we run
pnpm build
ourpackage.json
gets modifiedAnd this is bad, very bad. So the solution for this is to check if
exports
field contains
./dist
in it. It never should. We acomplish that with a customeslint rule you can find in
./eslint-local-rules.cjs
I hope you enjoyed as much as I did this little fairy tale πΉ
Importance
would make my life easier
Additional Information
I'm not sure if the goal of
svelte-package
is to place nice with monorepos. I'm not asking for an official solution. I'm just adding here my 2cents to see if someone have a better solution of if this solution can help others.The text was updated successfully, but these errors were encountered: