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.

This project is a fork of motdotla/dotenv. The difference is this project by default overrides system environment variables.

Non-NEXT_PUBLIC_ environment variables are only available in the Node.js environment, meaning they aren't accessible to the browser (the client runs in a different environment).

The fundamental problem with NODE_ENV stems from developers combining optimizations and software behavior with the environment their software is running on.

I'd advise against using NODE_ENV values to branch.

.env.production, .env.development, .env.test (depending on value of NODE_ENV)

FPThe functional programming submodule provides a better alternative to chaining: composition; which makes your code clean and safe and doesn't bloat your build.

annotated tags point to a tag object in the object database. git tag -as -m msg annot cat .git/refs/tags/annot contains the SHA of the annotated tag object: c1d7720e99f9dd1d1c8aee625fd6ce09b3a81fef and then we can get its content with: git cat-file -p c1d7720e99f9dd1d1c8aee625fd6ce09b3a81fef

Why file history can be important you ask In a commit ( or a series of commits ) there can be a lot of information that can explain decisions that were taken and why the code has evolved as it is right now. This information can be as valuable as the code itself so you can understand why I find --follow useful.

I would argue that "whole tree" thinking is enhanced by --follow being the default. What I mean is when I want to see the history of the code within a file, I really don't usually care whether the file was renamed or not, I just want to see the history of the code, regardless of renames. So in my opinion it makes sense for --follow to be the default because I don't care about individual files; --follow helps me to ignore individual file renames, which are usually pretty inconsequential.

You (and your collaborators) need to re-generate hooks every time there’s a change in .huskyrc.js. Re-generation could be bound to some events, but there’s no reliable way to cover all possible cases and unexpected behaviors would appear.

Since your hooks definition is not in one place anymore but in two (.huskyrc.js and .git/hooks/), suddenly you need boilerplate to keep JS world in sync with Git world.

Similarly, if you use register / sign in you avoid confusion, but you also fit common usage.

Google: Sign Out, Sign In, "Create an account"

If you use "register/log in", there is no chance of confusion, and you lighten the cognitive load.

I would be very careful with the "common usage" argument. For example: the use of sign up and sign in has a very pleasant symmetry which doubtless appeals to many people. Unfortunately, this symmetry reduces the difference by which the user recognizes the button she needs to just two letters. It's very easy to click sign up when you meant sign in.

"Log in" is a valid verb where "Login" is a valid noun. "Signin", however, isn't a valid noun. On the other hand, "Signup" and "Sign up" have the same relationship, and if you use "Log in", you'll probably use "Register" as opposed to "Sign up". Then there's also "Log on" and "Logon", and of course "Log off" or "Log out".

Not the third though - "Login" is a noun (if it is really a word at all): "What is your login?" The other two are verbs "to sign in", or "to log in".

In the case of email, it can be argued that the widespread use of the unhyphenated spelling has made this compound noun an exception to the rule. It might also be said that closed (unhyphenated) spelling is simply the direction English is evolving, but good luck arguing that “tshirt” is a good way to write “t-shirt.”

Your file structure might look something like this:

Vite's job is to get your source modules into a form that can run in the browser as fast as possible. To that end, we recommend separating static analysis checks from Vite's transform pipeline.

Vite uses esbuild to transpile TypeScript into JavaScript which is about 20~30x faster than vanilla tsc, and HMR updates can reflect in the browser in under 50ms.

Above: the time to do a production bundle

One important thing to remember is that in regular strings the \ character needs to be escaped while in the regex literal (usually) the / character needs to be escaped. So /\w+\//i becomes new RegExp("\\w+/", "i")

Your design should strongly depend from your purpose.

Ask yourself what is the main purpose of storing this data? Do you intend to actually send mail to the person at the address? Track demographics, populations? Be able to ask callers for their correct address as part of some basic authentication/verification? All of the above? None of the above? Depending on your actual need, you will determine either a) it doesn't really matter, and you can go for a free-text approach, or b) structured/specific fields for all countries, or c) country specific architecture.

However, don't force users to supply postcode or region, they may not be used locally.

Locality can be unclear, particularly the distinction between map locality and postal-locality. The postal locality is the one deemed by a postal authority which may sometimes be a nearby large town. However, the postcode will usually resolve any problems or discrepancies there, to allow correct delivery even if the official post-locality is not used.

naming the settlement (city/town/village), which can be generically referred to as a locality

n general, a locality is a particular place or location. More specifically, a locality should be defined as a distinct population cluster. Localities are commonly recognized as cities, towns, and villages; but they may also include other areas such as fishing hamlets, mining camps, ranches, farms and market towns. Localities are often lower-level administrative areas and they may consist of sub-localities, which are segments of a single locality. Sub-localities should not be confused for being the lowest level administrative area of a country, nor should they be confused as being separate localities.

The regions in which a country is divided into. Each region typically has a defined boundary with an administration that performs some level of government functions. These areas are commonly expected to manage themselves with a certain level of autonomy. Various administrative levels exist that can range from “first-level” administrative to “fifth-level” administrative. The higher the level number is the lower its rank will be on the administrative level hierarchy. For example, the US is made up of states (first-level), which are divided into counties (second-level) that consist of municipalities (third-level). For comparison, the United Kingdom (GB) is comprised of the four countries England, Scotland, Wales and Northern Ireland (first-level). These countries are made up of counties, districts and shires (second-level), which in turn are made up of cities and towns (third-level) and small villages and parishes (fourth-level). Other common terms for an administrative area are administrative division, administrative region, administrative unit, administrative entity and subdivision.

In the United States of America, (US), we commonly use the terms city, state and zip code when referring to addresses. While that may mostly work for a country like Mexico (MX), it is not appropriate for other countries like Japan (JP) where the country is divided into prefectures instead of states. Not all countries call their sub-region divisions the same thing and many countries have several levels of sub-divisions. To further complicate the matter, not all sub-division levels are necessarily interchangeable from one country to another. For example, a first level sub-region in the US is a state, such as California (US-CA), but a first level sub-region for the United Kingdom of Great Britain and Northern Ireland (GB) is a country, such as England (GB-ENG).

Every country can have its own particular set of terms and definitions; to try to go over them all would be too complicated and inefficient. Instead, let’s go over some commonly used terms that are helpful when talking about international addresses.

Thank you for an eye-opening answer – I had no idea native speakers don't really make the distinction! As for using "town" about cities, I was thinking more of the fact that dictionaries explain the meaning of "city" in terms of "large town", which to me indicates that "town" would be a hypernym of "town" and "city" in much the same way as "dog" is a hypernym of "dog" and "bitch", but I guess I've drawn the wrong conclusion here.

Plugins are ways of adding new languages or formatting rules to Prettier. Prettier’s own implementations of all languages are expressed using the plugin API.

(Do not confuse this with the --schema option, which uses the word “schema” in a different meaning.)

Some developers have the intuition that the file extension could be used to determine the module type, as it is in many existing non-standard module systems. However, it's a deep web architectural principle that the suffix of the URL (which you might think of as the "file extension" outside of the web) does not lead to semantics of how the page is interpreted. In practice, on the web, there is a widespread mismatch between file extension and the HTTP Content Type header. All of this sums up to it being infeasible to depend on file extensions/suffixes included in the module specifier to be the basis for this checking.

I use dashes -, for the reasons you mention above. I avoid underscores because they require using the shift key, so take at least twice as long to type (also, I think they're ugly)

With so many characters that you might not think should be special, in fact being special, I just use the special characters anyway. This also puts me in the good habits of using bash completion, where it will auto-escape all the special characters in a filename. But it also puts me in the good habits of escaping/quoting EVERYTHING in scripts and multi-part 1-liners in bash. For example, in just a simple 1-liner: for file in *.txt; do something.sh "$file"; done That way, even if one of the files has a space, or some other character, the do part of the loop will still act on it, and not miss on 2 or more file-name-parts, possibly causing unintended side-effects. Since I cannot control the space/not-space naming of EVERY file I encounter, and if I tried, it would probably break some symlinks somewhere, causing yet more unintended consequences, I just expect that all filename/directoryname could have spaces in it, and just quote/escape all variables to compensate. So, then I just use whatever characters I want (often spaces) in filenames. I even use spaces in ZFS dataset names, which I have to admit has caused a fair amount of head-scratching among the developers that write the software for the NAS I use. Sum-up: Spaces are not an invalid character, so there's no reason not to use them.

Some applications and computer scripts may not recognize spaces or will process your files differently when using spaces. A best practice is to replace spaces in file names with  an underline (_) or hyphen (-).