The future of @sveltejs/package
#8825
Replies: 9 comments 15 replies
-
What if we a command like Regarding this: is there something on the horizon about a way to access $app inside the package without wresting with vite (right now a vite plugin to add the package to the list of non optimizable dependencies is required)? |
Beta Was this translation helpful? Give feedback.
-
Tagging some package authors for visibility - @antony @rgossiaux @theetrain @endigo9740 @shinokada @Tropix126 would this change make sense to you or is the current behavior of copying over a package.json critical to you (and if yes, why)? Would the proposed way of doing things - manually authoring the |
Beta Was this translation helpful? Give feedback.
-
Personally, I'm very happy with the current workflow.
My understanding of the proposal is that the svelte-package would only validate the authored package.json and not generate a new one. We have to export explicitly what we are exporting in package.json. If a change needs to be made a migration guide with examples will be very helpful. |
Beta Was this translation helpful? Give feedback.
-
Current issues:
|
Beta Was this translation helpful? Give feedback.
-
Given the sentiment so far we feel that people are either slightly in favor, or ok with the change as long as they get a good migration script and good instructions for how to manage their export conditions (which is really the only thing that changes for people). |
Beta Was this translation helpful? Give feedback.
-
Run Vite on the contents of
|
Beta Was this translation helpful? Give feedback.
-
+1 for the monorepo use case. I'm building an app and website that shares UI elements, but with different build config, different routes, and different adapters. IIUC SvelteKit assumes 1:1 relation between package:app, in which case my ideal dep tree would be Judging by the web searches that brought me here, it seems a lot of people want to reuse their Svelte components in different sites, without necessarily publishing and maintaining libraries in the traditional sense. |
Beta Was this translation helpful? Give feedback.
-
i end up here while looking for ways to make svelte components composable. i have a monorepo setup with shared frontend package which uses pkgroll to build js modules. i don't use svelte kit. thanks to i see i don't know why it creates here is my setup for anyone interested. package.json contains independent js modules, svelte stores, actions and components: "exports": {
"./modules/dayjs.js": {
"import": {
"types": "./dist/modules/dayjs.d.ts",
"default": "./dist/modules/dayjs.js"
}
},
"./svelte/store/device.js": {
"import": {
"types": "./dist/svelte/store/device.d.ts",
"default": "./dist/svelte/store/device.js"
}
},
"./Banner.svelte": {
"types": "./dist/svelte/components/elements/LoadingBar.svelte.d.ts",
"svelte": "./dist/svelte/components/elements/LoadingBar.svelte"
},
}, svelte files packaged with: "scripts": {
"build:svelte": "svelte-package -i ./src/svelte/components -o ./dist/svelte/components",
}, using it like: import Banner from '@org/frontend-common/Banner.svelte' |
Beta Was this translation helpful? Give feedback.
-
I would prefer I also noticed the latest version generates "ts" (my code is in ts), which appears to break the entire REPL preview 5. |
Beta Was this translation helpful? Give feedback.
-
Update - implemented
See #8922 for details on how to migrate
Original description
Many of you are using
@sveltejs/package
to generate Svelte libraries. For the uninitiated, it provides asvelte-package
command that takes a directory as input — defaulting tosrc/lib
— and turns it into output suitable for publishing to npm. That means that.ts
files are converted to.js
, and.svelte
files that rely on preprocessors (TypeScript, SASS etc) are turned into 'vanilla' (but uncompiled) Svelte components. It also generates.d.ts
files, so that users of your library get type safety and autocompletion and what-have-you.It also does something slightly controversial: it generates a
package.json
for your library by copying over a subset of your authoredpackage.json
and including anexports
map, which is the preferred modern way to declare what can be imported from your package. This was designed to make publishing packages convenient, but in practice it has had the opposite effect — it's finicky to publish from a subdirectory, and monorepo tooling often freaks out about the generatedpackage.json
file. We're not the first people to do this — Angular does something similar — but that doesn't make it a good idea.(Speaking of monorepos, the current approach makes it very awkward to use packages created with
svelte-package
inside the same monorepo — you can't use e.g."my-library": "workspace:^"
because that will point to the package root rather than the generated directory. Instead you have to a) manually specifyexports
that point atsrc/lib
and somehow prevent drift, or b) use hackyoverrides
. It's a mess.)One solution to the problems caused by this approach would be to offer more customisation over the
package.json
— we currently exposeconfig.package.exports
andconfig.package.files
options (documented here, albeit tucked away), and #8808 implements that idea.But I think we should probably reconsider the whole approach, rather than doubling down on it.
Here's what I propose: radical simplification. We continue to do the
src/lib
->dest
transformation, but instead of generating apackage.json
for you, we simply validate that the one you authored is well-formed (i.e. yourexports
map points at real files indist
, and yourfiles
array will include everything imported by the things found inexports
, etc). We might not even need to do the validation in-house — we could simply add publint to the library template and include it in theprepublishOnly
script:The obvious downside is that no-one wants to bother setting up
exports
. But this is something you only touch rarely, and the current approach — hope thatsvelte-package
is accidentally doing the right thing — is hardly optimal. Packages that accept the default behaviour are likely exporting things that shouldn't be exported. By forcing people to be conscious and explicit we will improve the overall quality of the ecosystem, and by teaching people how to useexports
and usepublint
we will alleviate the problem of invalid packages being published to npm.Since this would be a fairly major departure, we'd want to provide an
npx svelte-migrate package
command.For some people, a
src/lib
->dist
step might be overkill. It's only really necessary if you're using.ts
files andlang="ts"
in your.svelte
files (or SASS, etc). If you're not doing that, you could just point yourexports
atsrc/lib
. An advantage of doing this is that you don't need to runsvelte-package
to be able to use the library in another project — this is how I write all my non-Svelte libraries and it's bliss.But it's still helpful to generate types for consumers. I typically do this with
tsc
— for example thetypes
directory in this package is generated from the JSDoc annotations in the.js
source code — and it would be nice to be able to do the same thing for Svelte libraries.To that end, perhaps — in addition to the simpler
svelte-package
command outlined above — we could also have something like this......which you'd use with
exports
like these:Beta Was this translation helpful? Give feedback.
All reactions