solid-primitives
solid-primitives copied to clipboard
solidjs-community
feat: create a `@solid-primitives/all` that exports all available packages
Would it be possible to create @solid-primitives/all that exports all available packages making it super easy to install and manage, especially since vite, esbuild, rollup, etc... all handle tree-shaking?
Right now to use some of solid-primitives alot of npm install's are require. 😅
While that would be possible, it would also require npm to download a lot of unused primitives. We don't want to waste bandwidth, disk space and time like that. Maybe let's rather add some small npx-able primitive installer that lets you add and remove primitives?
In the future, I want to try creating /core package, that would do that for Stage 4 packages. Right now there aren't any - so it could be a good determinant whatever the package should be updated too stage-4.
And since this package would be optional to download, the counter argument about wasted bandwidth/disc space shouldn't matter, because it would be for users to decide which way they prefer to install things.
@atk That could also work, but the @solid-primitives/all would be an alternative npm package if you want all the primitives without having to install them manually. If devs care all that extra stuff with network bandwidth, etc..., they'll manually install the primitives they want.
I think a collection package makes most sense for explorative use. If we do a @solid-primitives/all package, it should contain a script that scans the project for primitives used and replaces @solid-primitives/all in package.json with those packages actually used, so if you have finished exploring, you have an easy way to spare your fellow developers from downloading multiple MB of unused packages. I'm very much supportive of frugal JS: https://dev.to/lexlohr/a-new-paradigm-2k5l
I definitely hear @atk and @okikio opinions on this.
I personally would only prefer to have what I need installed. The reality is a user is going to be looking at the docs very often because it's difficult to memorize/keep track of all the primitive package options. Since they are on the page, the install path for the primitive is a copy and paste away. That seems reasonably easy. Also another argument is from a maintainers perspective, seeing granular installs gives us KPIs to know which packages are actively used and popular. An all package obfuscates that.
Putting the above arguments aside, there are some power users that make heavy use of Solid Primitives. Installing once and mindlessly being able to import everything you need in one shot is advantageous. I don't want us to be perceived as overly prescriptive to this crowd of adopters.
Perhaps the solution is to publish an all package and avoid publicizing or encouraging it. Users in the know and desire this solution would adopt it but we wouldn't encourage it.
@davedbase Why wouldn't you publicize it?
If devs want/need all packages give them the option to install all packages there is no need to dictate how devs install packages, devs are smart enough to determine if the bandwidth cost is worth the convience.
IMO, if you think installing individual packages is better then in the docs you state "we prefer users installing individual packages as it saves on band width, etc..."
As I said, an all package could be documented with something along the lines of: "This package is meant for explorative use, so if you're using all the primitives you need, consider running npx @solid-primitives/scripts/prune in order to rewrite your package.json to only install the primitives you use so your co-maintainers enjoy faster installation. Or don't; I'm just a README, not the police.".
Yeah that seems to be the fairest approach.
@okikio I don't mean to make a deal out of it, we have our opinion on the preferred use of the library that we'd like to promote. Offering options to make everyone happy though is definitely worth while.
How shall we action this? Anyone interested in submitting a PR?
One issue I see is, how would you define the version number for the all package? Automatically increment major/minor/patch according to whether a subpackage has incremented major/minor/patch? Might make for some large version numbers, but I imagine that's not a big deal.
On the other hand, I think using the all package would be difficult. If you need to update to get a new primitive, say, all other primitives would update to their latest versions (including major versions) and could easily have breaking changes. But if there's an easy script to "eject" to individual dependencies like @atk suggests, it wouldn't be a bad starting point.
FWIW, the fact that subpackages are released separately was one thing that sold me on the solid-primitives project. Otherwise adding new primitives would always have a feeling of global cost, and it'd be harder to experiment with new primitives and breaking changes. And it gives the feeling of lightness when installing just one primitive needed among dozens.
@edemaine Versioning the all packages isn't too difficult, changesets can automatically do that for you, including handling major, minor and patch versions of dependency packages.
Your 2nd and last points are good points, but the user opts into this behavior if they choose to use the all package and/or choose not to run npx @solid-primitives/scripts/prune. You're worries are valid but as long as we list these concerns in the docs, I think it'll be fine.
I would prefer single library, but I acknowledge this is ideological issue. Some people prefer even one function per NPM package vs batteries included libraries. I happen to like batteries included libraries.
To me biggest convenience of having single library would be the auto-completion would work faster.
If tree shaking works well enough then other functions are not bundled in the production app.
EDIT I meant with auto-complete the auto-import (ctrl + .) which can't work with packages one has not installed, but that's okay. With single library auto-import works for all functions.
I don't think auto-complete runs noticably faster if we use a single library vs. separate libraries. The main convenience point is not to have to select and install packages you want to use beforehand. I'll create an all package. I need a break from those fetch types anyways.
I would suggest releasing the full project under a solid-primitives package.
import { createFetch } from 'solid-primitives/fetch';
This will solve the conflict in names. But I am not sure about @solid-primitives/core.
