Remove the need for an index file with `npm run package`

[Rich-Harris]

Describe the problem

Following #2431, npm run package prints the following if you don't have an index.svelte, index.js or index.ts:

Cannot generate a "svelte" entry point because the "." entry in "exports" is missing. Please specify one or set a "svelte" entry point yourself

It's not very clear what this means.

Describe the proposed solution

My first instinct is to just try and make the language clearer, but really the issue here is that the "svelte" field is bad and we should get rid of it. Back in the day, it was added so that a package could export a compiled module alongside the uncompiled component: if your app was using Svelte (i.e. you were using a bundler plugin that knew how to interpret "svelte") you would get the component, but otherwise you would import the JS module.

This felt like a good idea at the time but it's really not. It's unwanted magic (if you want to expose both, do so, but explicitly), and it only works with a main entry point, at a time when there's a standardised way to express subpaths within packages.

Unfortunately, it persists, at least partly because we opted to use it as a signal that a given package should be forcibly included in noExternal so that it gets processed by Vite.

Possible solutions:

• add "svelte": true instead of a path
• if that's too breaky (since it's used for resolution by e.g. rollup-plugin-svelte), add a new field and update the Vite plugin to account for it. Something like "sveltekit": { "noExternal": true } or something. Then again that is weirdly Kit-specific
• update rollup-plugin-svelte etc so that we can just use a boolean
• emit an index.js that just throws an error when you import it, and point "svelte" at that
• work with the Vite team to come up with a new field that tells Vite to exclude a given package. This is probably the best approach since it's not Svelte-specific, and is directly related to the problem it solves, but would require external buy-in

Alternatives considered

No response

Importance

would make my life easier

Additional Information

This whole thing is my fault, sorry

[benmccann]

@pngwn expressed a desire to be able to distribute a fully compiled ESM version of a library for non-Svelte users. It would be distributed alongside the preprocessed Svelte source for Svelte users. How would we do this without the svelte entry field? Would we add a svelte field in the exports map in package.json?

[pngwn]

I feel like conditional exports would be the best approach here, yeah.

[einarpersson]

Since I'm no expert in vite, rollup, I'm not sure if this relates to this or belongs to another issue - but I would like to be able to fully control what dependencies to be included in the package. I have dependencies (not devDep) that are used in the production app, but are not needed in the core-package which I also would like to be able to publish from the same codebase. I have understood that dev-dependencies are excluded from the package, but would not moving things between dep-devDep risk messing up my application? I'd like to configure the package without interfering with my app.

I looked briefly at vitejs library-mode but couldn't get it to work.

(again, sorry if this is the wrong place, then I'll make another issue out of it. I thought it seemed as if it related to your discussions about telling vite what to include/exclude etc)

[bertybot]

@pngwn expressed a desire to be able to distribute a fully compiled ESM version of a library for non-Svelte users. It would be distributed alongside the preprocessed Svelte source for Svelte users. How would we do this without the svelte entry field? Would we add a svelte field in the exports map in package.json?

Honestly, that seems like the most standardized way of handling things as that's how Typescript works with the "types" field in esm modules.

Excuse my ignorance here but, couldn't we take advantage of a lot of Typescript's work here? Whereas, Typescript automatically looks for {filename}.d.ts with an optional "types" override. Svelte language tools could automatically look for {filename].svelte with an optional "svelte" override. Seems like an already established pattern that we should follow.