@benmccann is attempting to deploy a commit to the Svelte Team on Vercel.

A member of the Team first needs to authorize it.

we have to verify that generating version.js happens and is correctly commited/tagged. see sveltejs/kit#9969 for a discussion around this.

posted on changesets: changesets/changesets#1166

@tcc-sejohnson @dominikg one last thing I wanted to check on:

changeset version && pnpm -r generate:version && git add --all"

I'm not entirely sure what that's expected to cover. Right now packages/svelte/.gitignore has /src/shared/version.js. Is that okay or do we need to start checking this file into git?

@tcc-sejohnson @dominikg one last thing I wanted to check on:

changeset version && pnpm -r generate:version && git add --all"

I'm not entirely sure what that's expected to cover. Right now packages/svelte/.gitignore has /src/shared/version.js. Is that okay or do we need to start checking this file into git?

If we don't include it in git, then we can just rely on having it called during release. which is not ok in my opinion. I think all imports from our src to our src should be pointing at files in the repo.

This is partly why I was excited to see you calling build, so we could theoretically include the types here as well...

@tcc-sejohnson @dominikg one last thing I wanted to check on:

changeset version && pnpm -r generate:version && git add --all"

I'm not entirely sure what that's expected to cover. Right now packages/svelte/.gitignore has /src/shared/version.js. Is that okay or do we need to start checking this file into git?

Ah yeah, it'd need to be checked into git. That or we could run pnpm -r generate:version prior to release?

checking those files into git would help getting rid of the prepare script too

Ok, I've added version.js to git

This is partly why I was excited to see you calling build, so we could theoretically include the types here as well...

Ah, I might have misunderstood that comment. I thought you were unhappy I was calling build 😆 The types seem a bit different. With those you'd probably want them generated alongside the PR that changed the function signature so that you can review them then instead of making it part of the release. But then we'd need some kind of check to ensure that's happening. I think I'll leave that for a separate PR if someone wants to take a stab at it

we still should make sure that all package.json files in this workspace that should not be published are private: true. this includes things like the playground or any other new package. changesets is relentless and will publish stuff if it's not on the registry.

we still should make sure that all package.json files in this workspace that should not be published are private: true

we're okay for now. there's only two package.json files currently and they're both set appropriately:

$ find . -name package.json
./packages/svelte/package.json
./package.json

#8648 adds the playground but that is private too 👍 just another thing to keep in mind during PR reviews. we won't be adding loads of package.json so the risk is relatively small