You need to claim ownership on Visual Studio Code's installation directory, by running this command: sudo chown -R $(whoami) "$(which code)" sudo chown -R $(whoami) /usr/share/code

And, in the spirit of transparency, a GitLab core value, we like to share our rationale for typeface changes.

“Why does editing content… still feel like writing code?”

“Why does changing a headline… need a dev ticket?”

Subqueries can be used in any place where a table can be used, for example in joins:

For example, even a read-only transaction at this level may see a control record updated to show that a batch has been completed but not see one of the detail records which is logically part of the batch because it read an earlier revision of the control record.

a repeatable read transaction cannot modify or lock rows changed by other transactions after the repeatable read transaction began.

Because Read Committed mode starts each command with a new snapshot that includes all transactions committed up to that instant, subsequent commands in the same transaction will see the effects of the committed concurrent transaction in any case. The point at issue above is whether or not a single command sees an absolutely consistent view of the database.

Thus, successive SELECT commands within a single transaction see the same data, i.e., they do not see changes made by other transactions that committed after their own transaction started.

This marks a significant milestone in our commitment to transparency and community collaboration.

When you open this in two browsers and refresh a few times, one browser after the other, you’ll see the count go up and up (when looking at the page source), proving that the state is shared between both browsers (well, not really, it’s shared on the server, and used by both users). This will have serious consequences if you go this route: if user A is logged in and you’d write the user object to the shared state, and user B is not logged in, they’d still see a flash of user A’s username appear in the navigation bar, until the shared state is overwritten by the undefined user object.

export const state: State = $state({ user: undefined });

But sadly this introduces shared state on the server (when we use SSR), and this is a big problem since we’re now leaking data between different users.

One pattern that I love to use in my SvelteKit projects is returning writable stores from the layout’s load function. This makes it possible to fetch data from the server (for example the user object for the logged in user), and then you make this object available as a writable reactive store throughout the whole application. So when the user updates their username or avatar, you do the PUT request to the server and you get the updated user object back from the server as the response, you can simply update the $user writable store value and every place in your app where you show the user object gets updated immediately.

I don’t need to refetch all my server data just to refetch the user object, especially when it’s already right there in the response of my PUT request!

risk of accidentally exposing one user’s data to another

As with the previous example, this puts one user’s information in a place that is shared by all users.

You just got to be careful to never touch the global store from SSR!

For example, let’s say you fetch a list of books on the /books page and a list of albums on /albums page, so both those pages have a LayoutLoad method where the fetches are made. With SvelteKit this will cause the fetch to happen every time the user switches between these two pages, and the writable store will also be recreated every time. If your goal is to prevent refetching content you’ve already fetched before, then the global store is still your best bet.

conditionally returned either a readable store (from SSR) or a global writable store (from CSR) to make things like real time updates via WebSockets possible - although that solution does have one big advantage: the global store is always there.

But what if you want to update this user instance? For example on your website you have a form where the user can change their name, username, or avatar. When the form is submitted this gets stored on the server, but the site still shows the old user information, for example it still shows the old avatar of the user in the top menu. The user variable isn’t writable, so how do you overwrite this?

But with numeric enums, you can pass a raw number in places where the enum is expected. What?

If you're desperate to use enums, I'd strongly recommend using string enums only.

The Proposal: Possible upstreaming into GNOME The Problem: Why we need this in GNOME Installation: For those wanting to install this on their distribution The Solution: Shared Features: Behaviors shared between stacking and auto-tiling modes Floating Mode: Behaviors specific to the floating mode Tiling Mode: Behaviors specific to the auto-tiling mode Developers: Guide for getting started with development

Alternatively, you can also add it to compilerOptions.types field in your tsconfig.json file. Note that specifying anything in this field will disable auto loading of @types/* packages.

This way when you use client side routing, you will only receive the _data.json generated at build time and use that to populate the page component with required data (kinda like Next.js does it).

If you use a random URL then option b won’t work because you can’t invalidate a random URL using that method.

You can use args in your stories to configure the component's appearance, similar to what you would do in an application. For example, here's how you could use a footer arg to populate a child component:

When writing component tests that involve two-way bindings, context or snippet props, it’s best to create a wrapper component for your specific test and interact with that. @testing-library/svelte contains some examples.

Before writing component tests, think about whether you actually need to test the component, or if it’s more about the logic inside the component. If so, consider extracting out that logic to test it in isolation, without the overhead of a component

However, to do that, you have to put the $state value in a callback (or getter/setter object) in the parameters of the function. This feels rather clunky and un-Svelte like. Here's an example of what I mean.

let myObj = { ...$get({foo, bar}) }

Don't ask to be assigned a feature. There's no need to be assigned a feature or to reserve it. If you want to contribute, just ask questions, open issues or pull requests. History shows that contributors being assigned to tasks often don't finish them, but still blocks other contributors from picking them up.

Be explicit in the demo's intend. Eg. if you're building a demo for argTypes, don't create a Button.svelte component and Button.stories.svelte stories and come up with examples for how to write argTypes for buttons. Instead, build an ArgTypes.svelte component and stories that clearly and only demonstrates argTypes.

The user variable is shared by everyone who connects to this server.

Conceptually, that is. In reality, servers are often long-lived and shared by multiple users. For that reason it’s important not to store data in shared variables.

Yes, this is intended. You can do this with less boilerplate by doing export const selectedDateCtrl = $state({ selectedDate: new Date() })

If you’re coming from old Svelte: The $effect rune replaces the afterUpdate method (which is deprecated in Svelte 5), and The $effect.pre replaces the beforeUpdate method (which is also deprecated in Svelte 5).

Another shortcut available to diagnose where changes are coming from with the $inspect rune is to use: $inspect(variable).with(console.trace);

You can think of it a little like GraphQL's feature of only fetching the data your component needs to render, and nothing else.

If you prefer to write scripts that don't need to be passed into Vite Node, you can declare it in the hashbang. Simply add #!/usr/bin/env vite-node --script at the top of your file:

const imgUrl = new URL('./img.png', import.meta.url).href

There is no way to link PRs; you have to manually note changes in commit messagesIf changes are made to the parent, you have to rebase all of the child branches

Assess the team’s trunk-based development maturity. Ensure developers are comfortable with concepts like rebasing over merging, using short-lived branches, and rapid integration before layering on stacking.

to make Tailwind less opinionated and match browser defaults.

Vitest makes writing tests directly within your source code easy, eliminating the need for separate test files. This approach, known as in-source testing, is useful when you want to quickly test individual functions without the overhead of creating and managing separate test files.

Given that they are not used that frequently, we traded a smaller surface area for more explicitness.

Modifiers also were inconsistent, because most of them were only useable on DOM elements.

When shallow routing, you may want to render another +page.svelte inside the current page.

For larger projects with multiple interconnected components, monorepos can be a game-changer, providing efficient dependency management, atomic commits, simplified code sharing, and an improved developer experience.

Node_modules is the heaviest object in the universe for a reason.

Interact with live systems whenever feasible instead of mocking components to uncover potential integration issues.

There is growing support across tooling for a shared .ignore file as well. Precedence should likely be .prettierignore > .ignore > .gitignore.

It is more clean to have all those ignore files in package.json rather than: .gitignore .eslintignore .stylelintignore .prettierignore .whateverignore ...

To dig deep on this though, .gitignore isn't a standard. It's a well documented and familiar syntax from a specific, widely adopted, tool. Maybe we can even pretend the git implementation is a reference implementation too. There's no spec though and, importantly, it isn't considered a standard by the git maintainers themselves. That's why I kept calling it a quasi-standard in my original post.

Jane prefers her family name fully spelled out

There has been an attempt to systematize exit status numbers (see /usr/include/sysexits.h), but this is intended for C and C++ programmers. A similar standard for scripting might be appropriate. The author of this document proposes restricting user-defined exit codes to the range 64 - 113 (in addition to 0, for success), to conform with the C/C++ standard.

An update of /usr/include/sysexits.h allocates previously unused exit codes from 64 - 78. It may be anticipated that the range of unallotted exit codes will be further restricted in the future. The author of this document will not do fixups on the scripting examples to conform to the changing standard. This should not cause any problems, since there is no overlap or conflict in usage of exit codes between compiled C/C++ binaries and shell scripts.

This interface has been deprecated and is retained only for compatibility. Its use is discouraged.

BSD-derived OS's have defined an extensive set of preferred interpretations: Meanings for 15 status codes 64 through 78 are defined in sysexits.h.[15] These historically derive from sendmail and other message transfer agents, but they have since found use in many other programs.[16] It has been deprecated and its use is discouraged.

@GwynethLlewelyn, this answer describes the de facto standard, which in my experience is far more widely adopted (and hence should take precedence) over the proposal in sysexits.h.

From one obsessive, insane history editor to another, thanks for posting the question! ;D

For any new environments and databases, you can use just drizzle-kit migrate, and all the migrations together with init will be applied

When you run migrate on a database that already has all the tables from your schema, you need to run it with the drizzle-kit migrate --no-init flag, which will skip the init step. If you run it without this flag and get an error that such tables already exist, drizzle-kit will detect it and suggest you add this flag.

When you introspect the database, you will receive an initial migration without comments. Instead of commenting it out, we will add a flag to journal entity with the init flag, indicating that this migration was generated by introspect action

root@51a758d136a2:~/test/test-project# npx prisma migrate diff --from-empty --to-schema-datamodel prisma/schema.prisma --script > migration.sql root@51a758d136a2:~/test/test-project# cat migration.sql -- CreateTable CREATE TABLE "test" ( "id" SERIAL NOT NULL, "val" INTEGER, CONSTRAINT "test_pkey" PRIMARY KEY ("id") ); root@51a758d136a2:~/test/test-project# mkdir -p prisma/migrations/initial root@51a758d136a2:~/test/test-project# mv migration.sql prisma/migrations/initial/

While that change fixes the issue, there’s a production outage waiting to happen. When the schema change is applied, the existing GetUserActions query will begin to fail. The correct way to fix this is to deploy the updated query before applying the schema migration. sqlc verify was designed to catch these types of problems. It ensures migrations are safe to deploy by sending your current schema and queries to sqlc cloud. There, we run your existing queries against your new schema changes to find any issues.

Why another database schema migration tool? Dbmate was inspired by many other tools, primarily Active Record Migrations, with the goals of being trivial to configure, and language & framework independent. Here is a comparison between dbmate and other popular migration tools.

There is no shortage of command runners! Some more or less similar alternatives to just include:

Recipes that start with #! are called shebang recipes, and are executed by saving the recipe body to a file and running it. This lets you write recipes in different languages:

It isn't strictly necessary, but set -euxo pipefail turns on a few useful features that make bash shebang recipes behave more like normal, linewise just recipe: set -e makes bash exit if a command fails. set -u makes bash exit if a variable is undefined. set -x makes bash print each script line before it's run. set -o pipefail makes bash exit if a command in a pipeline fails. This is bash-specific, so isn't turned on in normal linewise just recipes.

A universal load function can return an object containing any values, including things like custom classes and component constructors. A server load function must return data that can be serialized with devalue

So what I've been doing is using bulidx to build images for multiple architectures then you can pull those images with docker compose. # docker-bake.hcl variable "platforms" { default = ["linux/amd64", "linux/arm64"] } group "default" { targets = [ "my_image", ] } target "my_image" { dockerfile = "myimage.Dockerfile" tags = ["myrepo/myimage:latest"] platforms = platforms } # Command docker buildx bake --push

FROM scratch COPY --from=0 /bin/hello /bin/hello

#!/usr/bin/env npx ts-node // TypeScript code Whether this always works in macOS is unknown. There could be some magic with node installing a shell command shim (thanks to @DaMaxContext for commenting about this). This doesn't work in Linux because Linux distros treat all the characters after env as the command, instead of considering spaces as delimiting separate arguments. Or it doesn't work in Linux if the node command shim isn't present (not confirmed that's how it works, but in any case, in my testing, it doesn't work in Linux Docker containers). This means that npx ts-node will be treated as a single executable name that has a space in it, which obviously won't work, as that's not an executable.

"ts-node": "dist/bin.js", 9+ "ts-script": "dist/script.js"

.allowUnknownOptions()

In order to fix #2554, I added a --script option to vite-node so it can be used in shebang! 🎊

Another limitation in this implementation is that passing other options in the shebang to vite-node won't work, as I expect exact indexes in order to figure out what are the arguments to forward. It's not perfect but I think it's good enough to unblock people like me as a start. 👍

It looks like ts-node achieved this by adding a --script-mode and a new bin script. TypeStrong/ts-node@1ad44bf

As I understand it, vite-node would need two changes when running scripts this way: The -- separator shouldn't be required, and all args should be considered args of the calling script. The tsconfig.json for the script should be used.

Using vite-node with a shebang enables no-build workflows for utilities in monorepos, which can reduce complexity and improves DX.

#!/usr/bin/env vite-node --script

If you prefer to write scripts that don't need to be passed into Vite Node, you can declare it in the hashbang.

Some ISPs are blocking or throttling SMTP port 25. Using port 587 is recommended.

If this seems arbitrary and confusing, we understand! It’s a convention, just like how most programmers need to learn zero-based array indexing and then at some point it becomes second nature.

obj.self = obj; stringified = devalue.stringify(obj); // '[{"message":1,"self":0},"hello"]'

TylerRick

There is recent update that enables such functionality - https://github.com/moby/buildkit/releases/tag/dockerfile/1.7.0-labs To work with it - add comment in the beginning of the Dockerfile # syntax=docker.io/docker/dockerfile:1.7-labs

Available in docker/dockerfile-upstream:master-labs. Will be included in docker/dockerfile:1.7-labs.

Use the syntax parser directive to declare the Dockerfile syntax version to use for the build. If unspecified, BuildKit uses a bundled version of the Dockerfile frontend. Declaring a syntax version lets you automatically use the latest Dockerfile version without having to upgrade BuildKit or Docker Engine, or even use a custom Dockerfile implementation.

I think the fact that it's so simple to add, makes the case to just keep it in userland.