Skip to content

OskarHulter/devtools-playground

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

7 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

This is a Next.js project bootstrapped with create-next-app.

CI Status Main

CI Status Dev

Last Push

Getting Started

TIP

The preferred way to manage Yarn is by-project and through Corepack, a tool shipped by default with Node.js. Modern releases of Yarn aren't meant to be installed globally, or from npm.

Start by enabling Corepack, if it isn't already; this will add the yarn binary to your PATH: corepack enable Then initialize a new project: yarn init -2 Updating Yarn Any time you'll want to update Yarn to the latest version, just run: sh``` yarn set version stable yarn install Yarn will then configure your project to use the most recent stable binary.


### TIP

Yarn also frequently ships Release Candidate builds. Use yarn set version canary should you need a feature not released on the stable channel yet. Those builds are very stable, the only difference with the regular channel being a more staggered migration between major as we implement new breaking changes.


# yarn patch

Prepare a package for patching.

### Usage
yarn patch <package>
Details
This command will cause a package to be extracted in a temporary directory intended to be editable at will.

Once you're done with your changes, run yarn patch-commit -s path (with path being the temporary directory you received) to generate a patchfile and register it into your top-level manifest via the patch: protocol. Run yarn patch-commit -h for more details.

Calling the command when you already have a patch won't import it by default (in other words, the default behavior is to reset existing patches). However, adding the -u,--update flag will import any current patch.


# yarn patch-commit
Generate a patch out of a directory.

### Usage

yarn patch-commit <patchFolder>
Details
By default, this will print a patchfile on stdout based on the diff between the folder passed in and the original version of the package. Such file is suitable for consumption with the patch: protocol.

With the -s,--save option set, the patchfile won't be printed on stdout anymore and will instead be stored within a local file (by default kept within .yarn/patches, but configurable via the patchFolder setting). A resolutions entry will also be added to your top-level manifest, referencing the patched package via the patch: protocol.

Note that only folders generated by yarn patch are accepted as valid input for yarn patch-commit.

yarn dlx
Run a package in a temporary environment.
yarn dlx create-react-app ./my-app
Details
This command will install a package within a temporary environment, and run its binary script if it contains any. The binary will run within the current cwd.

By default Yarn will download the package named command, but this can be changed through the use of the -p,--package flag which will instruct Yarn to still run the same command but from a different package.

Using yarn dlx as a replacement of yarn add isn't recommended, as it makes your project non-deterministic (Yarn doesn't keep track of the packages installed through dlx - neither their name, nor their version).


❯ yarn explain YN0006
━━━ YN0006 - SOFT_LINK_BUILD ━━━━━━━━━━━━━━━━━━━━━━━━━━━━

A package has build scripts, but is linked through a soft link.

For Yarn, a hard link is when a package is owned by the package manager. In 
these instances Yarn will typically copy packages having build scripts into a 
project-local cache so that multiple projects with multiple dependency trees 
don't use the same build artifacts. So what's the problem with so-called "soft 
links"?

Soft links are when the package manager doesn't own the package source. An 
example is a workspace, or a dependency referenced through the `portal:` 
specifier. In these instances Yarn cannot safely assume that executing build 
scripts there is the intended behavior, because it would likely involve mutating 
your project or, even worse, an external location on your disk that might be 
shared by multiple projects. Since Yarn avoids doing anything unsafe, it cannot 
run build scripts on soft links.

There are a few workarounds:

  - Using `file:` instead of `portal:` will cause a hard link to be used instead 
    of a soft link. The other side of the coin will be that the packages will be 
    copied into the cache as well, meaning that changing the package source will 
    require you to run `YARN_UPDATE_FILE_CACHE=1 yarn install` for your changes 
    to be taken into account.

  - You can manually run `yarn run postinstall` (or whatever is named your build 
    script) from the directory of the affected packages. This requires you to 
    know in which order they'll have to be called, but is generally the safest 
    option.

  - You can simply abstain from using build scripts with soft links. While this 
    suggestion might seem like a bad case of "fix a problem by not encountering 
    the problem", consider that build scripts in development might not be of the 
    best effect from a developer experience perspective - they usually mean that 
    you'll need to run a script before being able to see your changes, which is 
    often not what you seek.


yarn rebuild

### Get Started

First, run the development server:

```bash
npm run dev
# or
yarn dev
# or
pnpm dev
# or
bun dev

Open http://localhost:3000 with your browser to see the result.

E2E-Testing Be sure to set the environment variable NEXTAUTH_URL to the correct value. If you are running locally, as the documentation within .env.example mentions, the value should be http://localhost:3000.

In a terminal just run:

yarn test-e2e

To open the last HTML report run:

yarn playwright show-report test-results/reports/playwright-html-report Resolving issues E2E test browsers not installed Run npx playwright install to download test browsers and resolve the error below when running yarn test-e2e:

Executable doesn't exist at /Users/alice/Library/Caches/ms-playwright/chromium-1048/chrome-mac/Chromium.app/Contents/MacOS/Chromium Upgrading from earlier versions Pull the current version:

git pull Check if dependencies got added/updated/removed

yarn Apply database migrations by running one of the following commands:

In a development environment, run:

yarn workspace @sln/prisma db-migrate (This can clear your development database in some cases)

In a production environment, run:

yarn workspace @sln/prisma db-deploy Check for .env variables changes

yarn predev Start the server. In a development environment, just do:

yarn dev For a production build, run for example:

yarn build yarn start Enjoy the new version.

Yarn flat { "flat": true } If your package only allows one version of a given dependency, and you'd like to enforce the same behavior as yarn install --flat on the command line, set this to true.

Note that if your package.json contains "flat": true and other packages depend on yours (e.g. you are building a library rather than an application), those other packages will also need "flat": true in their package.json or be installed with yarn install --flat on the command line.

resolutions { "resolutions": { "transitive-package-1": "0.0.29", "transitive-package-2": "file:./local-forks/transitive-package-2", "dependencies-package-1/transitive-package-3": "^2.1.1" } } Allows you to override a version of a particular nested dependency. See the Selective Versions Resolutions RFC for the full spec.

Note that installing dependencies via [yarn install --flat] will automatically add a resolutions block to your package.json file.

Nested tsconfig

json"include": [ "../../apps/web/next-env.d.ts", "../types/*.d.ts", "../types/next-auth.d.ts", "**/*.ts", "**/*.tsx" ], "exclude": [ "dist", "build", "node_modules" ]

Localization

Since v11.0.0 next-i18next also provides support for client side loading of translations.

In some use cases, you might want to load a translation file dynamically without having to use serverSideTranslations. This can be especially useful for lazy-loaded components that you don't want slowing down pages.

More information about that can be found here.

Note that serverSideTranslations must be imported from next-i18next/serverSideTranslations – this is a separate module that contains NodeJs-specific code.

Also, note that serverSideTranslations is not compatible with getInitialProps, as it only can execute in a server environment, whereas getInitialProps is called on the client side when navigating between pages.

The serverSideTranslations HOC is primarily responsible for passing translations and configuration options into pages, as props – you need to add it to any page that has translations.

About

No description, website, or topics provided.

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published