V3 🎉

[simeydotme]

Re-write in SvelteKit and Typescript.

(yay types for all you weird type nerds!)

---

• test folders with examples of the project running in many environments (react, vue, jquery, esm modules, svelte 5)
• types
• insanely complicated build system and package json
• some types
• code utils split out

Hope this goes smoothly for y'all who want to upgrade because of the slightly annoying cautions in your build systems! 🤞

---

This discussion was created from the release V3 🎉.

[simeydotme]

If anyone has some comments/issues... drop them in here for dicussion!

I'm also going to need to re-do the entire Astro Docs site 🙈 ... oh god.
What version is that even on now??

[simeydotme]

I was surprised I had to import { RangeSlider }, but if I import it with:

import RangeSlider from 'svelte-range-slider-pips'

Oh, i also fixed this so both work now, not sure if that's good or not

[kelvinsjk]

Thanks for the hard work!

Will be happy to help out with the documentation, so do give a holler if there's anything I can help with.

Some thoughts about documentation setup:

• Since the library is now built with SvelteKit packaging feature, one option is to use SvelteKit itself to do up the docs. (As mentioned on the SvelteKit docs, "src/routes might be a documentation or demo site that accompanies the library...".
  • Pros: Code base is simpler with no need for a separate workflow for docs
  • Cons: We will lose all the astro niceties, such as the Code component, navigation (sidebar and ToC) and theming.
• If sticking with astro, Astro Starlight, Astro's official documentation framework, may be something to consider. Fingers crossed the existing mdx files should port over nicely
• For a docs site in Astro, do you want to consider changing this to a monorepo setup? Codebases I've been following (like Svelte have been adapting a monorepo setup with pnpm workspaces with the library in a packages folder and the docs in a sites folder.
  • Pros: Both the docs and library lives in the same git branch. The current docs import the 'svelte-range-slider-pips' npm package, which means it may get out of sync. Importing from a workspace will mean that we get to see the latest version of the library within the docs without the publish and import steps.
  • Cons: Restricted to using pnpm

[simeydotme]

thanks for the great suggestions!

question regarding monorepos, though; would placing multiple packages (library + docs) into a single git repo mean that any time I fixed a bug/typo into the Docs, the version number for the parent package would change (even though, to the consumer, there is no actual change to the library)

I'm not adverse to the idea, because technically I already have this kind of setup running with the /test/ folder (bad naming, really)

I think I'd prefer to stick with Astro just because of the nice template and starlight theme. When I built the docs originally the template/theme I used was a fork of starlight (i think) because starlight was still very new and had a lot of limitations and issues... but I believe it's a lot better now and could probably simplify some of the components.

One thing I was very keen on and put a lot of effort into was having tiny stand-alone components/chunks that both served as the runnable-component, and the code that is displayed as a snippet for copy/paste; https://github.com/simeydotme/svelte-range-slider-pips/blob/astro-pages/src/components/Demos/examples/float/Float.svelte ... this feels really good when building/editing and means that I never accidentally wrote buggy code for copy/paste and I never had to test the code (the test was the demo working)

[kelvinsjk]

The package versions will be kept separate. Each package in the monorepo (ie the library itself and the docs site) will have their own package.json and hence their own version.

For my beginner level workflows I kind of use the two folders separately (ie do the npm publish inside the library folder itself and then let vercel do their work to handle updates on the docs folder (not sure how github pages will work for that)).

I've seen other authors coordinate the workflow from the root of the monorepo, with its own root package.json, though.

I tried this idea out in a fork, where I

• moved the files and folders in the project root into packages/svelte-range-slider-pips
• added a pnpm-workspace.yaml file with the following:

packages:
  - 'packages/*'
  - 'sites/*'

• moved the files and folders from the root of the branch astro-pages into sites/docs
• modified the package.json file in the docs from

"svelte-range-slider-pips": "^2.2.2",

to

"svelte-range-slider-pips": "workspace:*",

Locally running pnpm dev on packages/svelte-range-slider-pips and on sites/docs seem to get the intended results.

[simeydotme]

🥺

ooo, i'll have a look at this later :D

[simeydotme]

Ok, I just updated the immutable to false (it got lost when I moved to Vite bundler) and have tried to fix the exports.

[Gurimarukin]

Default import works again for me. I don't know which one is better, but I'd say default is the normal behaviour for a Svelte component, and it is one less breaking change ^^

Some of my sliders work again, but I have one which still doesn't slide. I'm trying to investigate.

[simeydotme]

I think the SvelteKit Library scaffold sets up to have a large number of library components exported by default, so that's probably why it was done that way. I just didn't think to check it 😂