Setup

• Unit/Svelte tests are done with Playwright: npm run playwright
• Code tests are done with Vitest: npm run vitest
• Testing everything: npm run test

We need to differentiate what testing library should be used based on what type of test is written. I propose the following naming convention:

*.spec.ts == test with Playwright *.test.ts == test with Vitest

Please let me know if you have any thoughts here!

Tests written

I've written the following tests as a MVP check:

• clickoutside action
• random meta utility method
• resettable store

How we test Svelte stuff

We need the ability to have test-components when testing things like actions. There is a lot of annoying pitfalls regarding the import of a Svelte component into a TypeScript file (which playwright uses). Playwright also looks for some stuff in .svelte-kit/output when running the tests (not exactly yet sure why, not really that interesting).

To solve these issues I've created a setup script which does the following:

1. Build the project if .svelte-kit/output is empty
2. Compile all *.svelte files in /test to their JS output. Compiling /test/clickoutside/Component.svelte will create a /test/clickoutside/Component.svelte.js file. This is somewhat elegant because the import Component from ./Component.svelte statement in the test file will then point to the JS file instead of the Svelte file. These autogenerated *.svelte.js are currently gitignored.

This setup script runs once before every npm run playwright call.

A challenge we need to fix

I have not yet found a way to support Svelte-kit in the tests. Imports like import { page } from "$app/stores" doesn't make any sense in a normal TypeScript context, and the stores also won't work unless we are in a Svelte-kit context. I'm not sure what the best way is to solve this issue. In the Vitest tests i think the easiest solution is to mock the imports (haven't tried, but Vitest has a great API for mocking imports). It's a little but tricker in the Playwright tests, but there should be a way to solve this.

I wanted to take a deeper look at the codebase, and while i did that i applied some refactorings.

This pr includes:

• style changes, e.g. removing variable/function names in snake_case instead of camelCase
• refactoring/enhancements, e.g. updated the clone function, refactored localstorage.ts
• fixes, e.g. a store leak
• fixing some ts definitions

Great work on the testing implementation! I fixed a couple typos that I encountered while reading the README and added a word ("and") that I think is missing.

I've tried a couple of ways but none copies the content of textarea. copy works fine with other elements (div, p, pre, etc).

<textarea
id="copyArea"
bind:value={fixedCopy}
/>

<textarea
id="copyArea">
{fixedCopy}
</textarea>

<button use:copy={'#copyArea'}>	Copy </button>

When you pass in portal with an HTMLElement rather than id reference, the code does not mount.

steps to repro:

<div bind:this={target} />
<p use:portal={target} />

Also the docstring is incorrect.

Checklist to prevent unintended side events:

• [x] create org in GitHub
• update repo link in package.json
• update links in docs
• update reddit post, update discord post
• update links in README.md
• update Vercel repo link

Definitely something that should be added as early as possible, will make the library a lot more appealing, and it's a lot easier beginning with it from the get-go instead of having it as a technical debt. Also makes it easier for other people to contribute/fix issues.

Hi Nikolai, great work setting up this library!

The community definitely deserves a utility library like this, and to me it seems like the obvious solution for "extending" the behaviour of Svelte. Here's a couple of reasons why i believe a library like this is a good idea:

• The Svelte API is by design as lean and extensible as possible - so the framework will never be filled with tons of utility functions.
• It follows the philosophy of having as few dependencies as possible. 1 big utility library with no other dependencies > 10+ small utility libraries with no other dependencies
• A lot of people will end up writing the same utility functions just to avoid installing other packages. I have a hypothesis that people will eventually get bored of this, and developers will begin looking after libraries that deliver solutions to this, e.g svelteui

Making an open source project popular is no easy job, and it requires a lot of marketing work. The code obviously has to be well written, but looking at the source code i have no doubt that this will be a problem. However, there are a couple of issues that I'd like to address:

• The docs. I'm not sure if this is the place to be experimental and create something "completely new". The docs page is cool and all, but users don't want a funky docs page. They want something familiar, easy to navigate and dead-simple to use. Search-functionality is also a must.
• The name/branding. This may just be a personal preference, but i feel like svelte libraries that try to integrate the "sv" prefix into their names sound a little corny. Even Rich Harris himself does not do this. A good open source project needs its own brand, and should tell its own story. The readme is important here.
• Personal vs organisation. There is nothing wrong with this project being on your personal account, but I believe that others are more likely to engage the project if they work for an organisation instead of a person. This also makes it easier to develop other tools in the organisation and expand if necessary.
• Other stuff for scaling; changelogs, pr-templates, issue-templates etc. Not the most important stuff in the beginning, but getting these right is a big, big plus.

The job you've done here is amazing Nikolai, you should be proud! You've caught my attention, and i have a feeling this can be the start of something great for the community!

transform actions (from svelte-transform lib) lazyload (but good) pannable / touch actions scrolldrag (for horizontal scrolling on carousels) dnd (dragging between multiple containers)