Most complex software ships with a few bugs. Obviously, we want to avoid them, but the more complex a feature is, the harder it is to cover all the use-cases. As we get closer to our RC date, do we feel confident that what we're shipping has as few blocking bugs as possible? I would like to say we're close, but the truth is I have no idea. It feels like we'll have to keep trying the features for a bit until we don't run into anything - but we have less than 3 weeks before the RC ships. Here's a few surprising bugs that need to get fixed before I would feel comfortable shipping node12 in stable.

however, the feature is much more expansive, and over the past few weeks, a few of us have grown a bit concerned about the complexity.

My repos are not the place to ask ESM/TypeScript/Webpack/Jest/ts-node/CRA support questions.

The snapport is the area of the scroll container to which the snap areas are aligned. By default, it is the same as the visual viewport of the scroll container, but it can be adjusted using the scroll-padding property.

#gallery { scroll-snap-type: x mandatory; overflow-x: scroll; display: flex; } #gallery img { scroll-snap-align: center; }

a user script initiated scroll

You may have noticed that these two properties do not have the word "snap" in them. This is intentional as they actually modify the box for all relevant scroll operations and are not just scroll snapping.

In your example you would simply say approved. The addition of the prefix pre has no meaning for words such as approve. It implies something that is done before approval. Therefore, pre-approved means not yet approved. You do find meaningless phrases like pre-approved and pre-booked used by marketers and advertisers but they cannot be recommended in good English.

Like the Elliptic curve Diffie-Hellman (ECDH) protocol that Signal has used since its start, KEM is a key encapsulation mechanism. Also known as a key agreement mechanism, it provides the means for two parties who have never met to securely agree on one or more shared secrets in the presence of an adversary who is monitoring the parties’ connection. RSA, ECDH, and other encapsulation algorithms have long been used to negotiate symmetric keys (almost always AES keys) in protocols including TLS, SSH, and IKE. Unlike ECDH and RSA, however, the much newer KEM is quantum-safe.

Not a medium member ? You can read the article for free here.

You should be able to, if you have at the top: vi.mock('node:fs', () => { return { existsSync: vi.fn(), }; });

All vi.mock calls are placed at the top of the file, and it's the first thing that's getting called. To change implementation for different tests, you can do: vi.spyOn(fs, 'existsSync').mockImplementation(() => { // new implementation })

make sure to prefix module names with node: when mocking node modules. It took me a while to figure this out... and it's not in the docs.

While a screen reader will announce the label of the form control receiving focus, the screen reader will not announce anything before the label, and the sighted user on a small device will equally miss the context created by the preceding content.

autofocus is 100% legitimate feature of HTML5, and just because it can be abused it shouldn't be triggering warnings.

Warning on something that is key feature a lot of major websites use makes no sense. The alternative of focusing the main input with js is not an improvement at all.

I came here after getting this warning during the build process and was confused as to why. The mdn webdocs specifically says "The autofocus attribute should be added to the element the user is expected to interact with immediately upon opening a modal dialog."

Also just because some popular websites does something doesn't mean you should too. WebAIM Million 2021 revealed that 97.4% of the top 1 million home pages had detectable WCAG 2 errors (not warnings). They found that 40% of home pages had skipping heading levels; developers aren't exactly great at picking the right tool for the job, not even the developers of the most popular sites.

More actionsWarnings make sense in two cases: something should just not be used ever, as it has no legitimate uses, or extremely rare there exists a better alternative In this case both are false. autofocus has many legitimate uses - including literally Internet's most popular website; and the alternatives of hand-writing JS code doing the pre-focusing, or not pre-focusing are both actively worse. Therefore this warning needs to go. (and all other warnings that don't fit into those two categories)

Handlebars will not escape a Handlebars.SafeString. If you write a helper that generates its own HTML, you will usually want to return a new Handlebars.SafeString(result).

Making new features easy to understand and polyfill introduces a virtuous cycle:

Developers can ramp up more quickly on new APIs, providing quicker feedback to the platform while the APIs are still the most malleable. Mistakes in APIs can be corrected quickly by the developers who use them, and library authors who serve them, providing high-fidelity, critical feedback to browser vendors and platform designers.

When npm released support for trusted publishing, it was our intention to let adoption of this new feature grow organically.

Set up Ruby

You can also use bind:property={get, set}, where get and set are functions, allowing you to perform validation and transformation:

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: