profile
viewpoint
Maël Nison arcanis @datadog Paris, France Lead maintainer for @yarnpkg 📦🧶 Senior Software Engineer @DataDog, ex @facebook, @sketchfab, ...

animatedjs/animated 1743

Declarative Animations Library for React and React Native

arcanis/clipanion 209

Type-safe CLI library with no dependencies

arcanis/build-pnm 3

Generate package-name-maps files by consuming the PnP API

arcanis/apollo-link-debounce 1

An Apollo Link that debounces requests

arcanis/chenille 1

Keep master green at all times

pull request commentyarnpkg/berry

Publish tarballs to repository

Honestly, I'm not sure this is a command we really want in the core ...

  • On one hand, it would certainly be useful in some cases. For example, Yarn's deploy process is creating multiple times the same archive, and being able to build them once in all the steps and reuse it rather than rebuilding would improve that quite a bit.

  • On the other hand, dissociating the packing from the publishing leads to annoying ambiguities. For instance, we currently look at publishConfig.registry to know where to publish the package. Where should we look? The one inside the packed tarball, or the one inside the project?

So I'm still on the fence about adding this ...

Kuinox

comment created time in 4 hours

issue openedarcanis/pmm

Cannot install if /tmp is in a separate drive

We currently use rename, so the temporary directory can't be moved if on a different drive than where we're installing the versions. We should change the temporary directory to instead be next to the final location, or at least within the ~/.node folder (this way we're sure they're on the same drive as the destination).

created time in 7 hours

issue openedarcanis/pmm

Init workflow

This thread is meant to discuss the init workflow. For example, what happens when running yarn init or npm init? Under the current model those commands will fail, because pmm is implemented in such a way that the package.json is created before spawning the process, which will then detect the preexisting manifest and refuse to update it.

created time in 7 hours

issue commentarcanis/pmm

Global packages

My opinion about this is that the current behaviour isn't a problem. Justifications:

  • Under the current model, npm is unmodified, so users would be able to use npm install -g or npx regardless of the package manager for the current project. This reason alone makes this problem non-blocking, although it's an interesting discussion nonetheless.

  • Using pnpx on a Yarn project (or even npx, even if not applicable because of the first point) may be dangerous. For example, we are looking to make yarn dlx (the Yarn equivalent) persist some parts of the local configuration (for example custom registries). Using a different package manager for the "x" command would lead to installs being made based on the incorrect configuration, so packages would be installed from the wrong registry.

  • The initial point that "projects decide which package managers they are meant to be used with" doesn't apply here, because global commands aren't cloning them - they are installing them, as any other command. For this reason, requiring to use yarn dlx on Yarn projects (rather than allowing pnpx) won't have negative effects.

arcanis

comment created time in 7 hours

issue openedarcanis/pmm

Global packages

This thread aims to discuss the "global packages" scenario. For example, the pmm version of pnpx --version currently prompts for project initialization if run within a Yarn project.

created time in 7 hours

pull request commentyarnpkg/berry

feat(pnp): better builtin not found error with considerBuiltins disabled

Good idea 👍

That said, the std namespace is more from a public API interface (for example adding a new function, or a new parameter, or changing a return type) - I'm not sure there's really a need to bump it here 🤔

paul-soporan

comment created time in 7 hours

pull request commentyarnpkg/berry

Mark `--frozen-lockfile` as a warning in Travis CI

Perfect, thanks!

dubzzz

comment created time in 8 hours

push eventyarnpkg/berry

Nicolas DUBIEN

commit sha 6ce1701647b3dc98fc67bf687e4b15651e5589f2

Mark `--frozen-lockfile` as a warning in Travis CI (#1693) * Mark `--frozen-lockfile` as a warning in Travis CI * Remove trailing whitespace * Run `yarn version check -i` * Move to ci-info

view details

push time in 8 hours

PR merged yarnpkg/berry

Mark `--frozen-lockfile` as a warning in Travis CI

What's the problem this PR addresses? <!-- Describe the rationale of your PR. --> <!-- Link all issues that it closes. (Closes/Resolves #xxxx.) -->

Travis CI is calling yarn --frozen-lockfile by default and that behaviour cannot be overriden (as far as I know). When bumping from Yarn to Berry it make builds crash at start-up on Travis.

This PR shows that Travis can be detected by using the check !!process.env.TRAVIS && !!process.env.CI.

Associated Travis build can be seen here: https://travis-ci.com/github/dubzzz/fast-check/builds/179306747 (by the way you can see that this job automatically calls yarn --frozen-lockfile)

And uses the following Travis configuration file: https://github.com/dubzzz/fast-check/blob/fa7e754eb5e4c4e348e8813469dbd964a9d70610/.travis.yml

How did you fix it? <!-- A detailed description of your implementation. -->

I changed the error into a warning for Travis CI as suggested by @arcanis on Twitter.

Checklist <!--- Don't worry if you miss something, chores are automatically tested. --> <!--- This checklist exists to help you remember doing the chores when you submit a PR. --> <!--- Put an x in all the boxes that apply. -->

<!-- See https://yarnpkg.com/advanced/contributing#preparing-your-pr-to-be-released for more details. --> <!-- Check with yarn version check and fix with yarn version check -i -->

  • [x] I have set the packages that need to be released for my changes to be effective.

<!-- The "Testing chores" workflow validates that your PR follows our guidelines. --> <!-- If it doesn't pass, click on it to see details as to what your PR might be missing. -->

  • [x] I have verified that all automated PR checks pass.
+34 -1

3 comments

5 changed files

dubzzz

pr closed time in 8 hours

issue commentyarnpkg/yarn

Running a yarn command with yarn sets registry to https://registry.yarnpkg.com

Any way this can be addressed by Yarn team? (@torifat ?) Currently on yarn@1.16.0.

You are five minors late, and one major too 🙂

ericsoco

comment created time in 8 hours

pull request commentyarnpkg/berry

Mark `--frozen-lockfile` as a warning in Travis CI

Sounds good to me (intuitively I'd probably try to drop the CI check to only care about TRAVIS, but if that's what is-ci does ... 🤷‍♀️). Can you run yarn version check -i and mark essential and cli for patches (and put the rest on decline)?

Btw, did you try it in practice? You can run yarn set version from sources --branch 1693 to apply it to your own repository.

dubzzz

comment created time in 10 hours

issue closedyarnpkg/berry

[Feature/Bug] Support for `yarn check`

  • [ ] I'd be willing to implement this feature
  • [ ] This feature can already be implemented through a plugin

Describe the user story

Is there an alternative to v1's yarn check? My team has done the v2 upgrade but is reliant on yarn check to confirm whether all the modules have been installed as expected.

Note: we are supporting node_modules on v2 and not using the zero install approach (yet).

closed time in a day

pam-

issue commentyarnpkg/berry

[Feature/Bug] Support for `yarn check`

This command was deprecated a long time ago due to being largely pointless. More details: https://github.com/yarnpkg/rfcs/blob/master/accepted/0000-remove-yarn-check.md

pam-

comment created time in a day

Pull request review commentyarnpkg/berry

feat(fslib): add types for absolute/relative paths

 export interface FormatInputPathObject<P extends Path> {   name?: Filename; } -export interface PathUtils<P extends Path> {-  cwd(): P;+export type MakeAbsolute<P> = P & (P extends PortablePath ? AbsolutePortablePath : AbsoluteNativePath);+export type MakeRelative<P> = P & (P extends PortablePath ? RelativePortablePath : RelativeNativePath);++export interface PathUtils<P extends Path, AP extends P = MakeAbsolute<P>, RP extends P = MakeRelative<P>> {+  cwd(): AP; -  normalize(p: P): P;+  normalize<T extends P>(p: T): T;++  join(initial: AP, ...paths: Array<P|Filename>): AP;+  join(initial: RP | Filename, ...paths: Array<P|Filename>): RP;   join(...paths: Array<P|Filename>): P;-  resolve(...pathSegments: Array<P|Filename>): P;-  isAbsolute(path: P): boolean;-  relative(from: P, to: P): P;-  dirname(p: P): P;+  resolve(...pathSegments: Array<P|Filename>): AP;

Perhaps an option would be to make ZipFS & co generic on an "options" parameter:

declare const zipFs: ZipFS<NoRelative>;

declare const p: Path<Portable>;
declare const rel: Path<Portable & Relative>;
declare const abs: Path<Portable & Absolute>;

// Doesn't work
zipFs.readFileSync(p);
zipFs.readFileSync(rel);

// Works
zipFs.readFileSync(abs);

This option would default to false (allows relative), but xfs would default to true, for enforced strictness.

bgotink

comment created time in a day

Pull request review commentyarnpkg/berry

feat(fslib): add types for absolute/relative paths

 enum PathType {   Native, } -export type PortablePath = string & { _path_type: PathType.File | PathType.Portable };-export type NativePath = string & { _path_type?: PathType.File | PathType.Native };+enum PathRelativity {+  Absolute,+  Relative,+}++export type AbsolutePortablePath = string & {+  _path_type: PathType.File | PathType.Portable;+  _path_relativity: PathRelativity.Absolute;+};+export type AbsoluteNativePath = string & {+  _path_type?: PathType.File | PathType.Native;+  _path_relativity: PathRelativity.Absolute;+};+export type RelativePortablePath = string & {+  _path_type: PathType.File | PathType.Portable;+  _path_relativity: PathRelativity.Relative;+};+export type RelativeNativePath = string & {+  _path_type?: PathType.File | PathType.Native;+  _path_relativity: PathRelativity.Relative;+};

What about using & instead of |? Cf Playground Link.

bgotink

comment created time in a day

Pull request review commentfacebook/jest

Add `.pnp.js` to `transformIgnorePatterns` defaults

 exports[`--showConfig outputs config info and exits 1`] = `         ]       ],       "transformIgnorePatterns": [-        "/node_modules/"+        "/node_modules/",+        "\\\\.pnp\\\\.c?js$"

I'd go with \\.pnp\\.[^\\\/]+, and refine if it causes problems in practice.

irudoy

comment created time in 2 days

Pull request review commentyarnpkg/berry

feat(fslib): add types for absolute/relative paths

 export interface FormatInputPathObject<P extends Path> {   name?: Filename; } -export interface PathUtils<P extends Path> {-  cwd(): P;+export type MakeAbsolute<P> = P & (P extends PortablePath ? AbsolutePortablePath : AbsoluteNativePath);+export type MakeRelative<P> = P & (P extends PortablePath ? RelativePortablePath : RelativeNativePath);++export interface PathUtils<P extends Path, AP extends P = MakeAbsolute<P>, RP extends P = MakeRelative<P>> {

Just to be sure I understand - the TS playground you shared use the generic parameters, but still has the bogus behaviour you describe, is that expected? Or are those two different problems?

If this bug would affect us even with the generics, perhaps we should open an issue on the TS repo to see if they have an idea what might cause this.

bgotink

comment created time in 2 days

Pull request review commentyarnpkg/berry

feat(fslib): add types for absolute/relative paths

 export interface FormatInputPathObject<P extends Path> {   name?: Filename; } -export interface PathUtils<P extends Path> {-  cwd(): P;+export type MakeAbsolute<P> = P & (P extends PortablePath ? AbsolutePortablePath : AbsoluteNativePath);+export type MakeRelative<P> = P & (P extends PortablePath ? RelativePortablePath : RelativeNativePath);++export interface PathUtils<P extends Path, AP extends P = MakeAbsolute<P>, RP extends P = MakeRelative<P>> {+  cwd(): AP; -  normalize(p: P): P;+  normalize<T extends P>(p: T): T;++  join(initial: AP, ...paths: Array<P|Filename>): AP;+  join(initial: RP | Filename, ...paths: Array<P|Filename>): RP;   join(...paths: Array<P|Filename>): P;-  resolve(...pathSegments: Array<P|Filename>): P;-  isAbsolute(path: P): boolean;-  relative(from: P, to: P): P;-  dirname(p: P): P;+  resolve(...pathSegments: Array<P|Filename>): AP;

So that's the main problem I can see with this approach. The initial tweet was about a bug where a relative path was unexpectedly resolved relative to the cwd - but apart from that, the construct was technically fine per the fs prototypes: resolve is just fine with both relative and absolute paths.

So to fix the initial issue, we'd either have to type Resolve to forbid relative paths as first parameter (but that would be technically incorrect since the patched fs would still accept both relative and absolute paths), or make xfs a "stricter" version of fs where relative paths aren't allowed as paths.

What do you think about this?

bgotink

comment created time in 2 days

Pull request review commentyarnpkg/berry

feat(fslib): add types for absolute/relative paths

 enum PathType {   Native, } -export type PortablePath = string & { _path_type: PathType.File | PathType.Portable };-export type NativePath = string & { _path_type?: PathType.File | PathType.Native };+enum PathRelativity {+  Absolute,+  Relative,+}++export type AbsolutePortablePath = string & {+  _path_type: PathType.File | PathType.Portable;+  _path_relativity: PathRelativity.Absolute;+};+export type AbsoluteNativePath = string & {+  _path_type?: PathType.File | PathType.Native;+  _path_relativity: PathRelativity.Absolute;+};+export type RelativePortablePath = string & {+  _path_type: PathType.File | PathType.Portable;+  _path_relativity: PathRelativity.Relative;+};+export type RelativeNativePath = string & {+  _path_type?: PathType.File | PathType.Native;+  _path_relativity: PathRelativity.Relative;+};

Do you think it would make sense to turn that into "bitfields"? For example, instead of RelativePortablePath, we'd have Path<Portable | Relative> (and Path<Portable> would accept both relative and absolute paths). Might be more scalable, if we want more types of paths? 🤔

bgotink

comment created time in 2 days

issue closedyarnpkg/berry

[Bug] Nondeterministic build script execution for the case of monorepo workspace

Describe the bug

Build scripts launching inside monorepo workspaces can be nondeterministic

To Reproduce

<details> <summary>Reproduction</summary>

await packageJson({
  workspaces: [`packages/common`],
  dependencies: {
      [`common`]: `workspace:*`
  },
  scripts: {
    postinstall: `echo monorepo`
  }
});

await packageJson({
name: `common`,
version: `1.0.0`,
scripts: {
  postinstall: `echo common`
}
}, {cwd: `./packages/common`});

const outFresh = await yarn()
expect(outFresh).toContain(`STDOUT common`)
expect(outFresh).toContain(`STDOUT monorepo`)

const outAdd = await yarn('workspace', 'common', 'add', 'lodash')

expect(outAdd).toContain(`STDOUT common`)
expect(outAdd).toContain(`STDOUT monorepo`)

</details>

closed time in 3 days

larixer

push eventyarnpkg/berry

Kristoffer K

commit sha ae0812cd0910b782e7df65e96935c0ee5879784b

perf(cli): perform async temp cleanup (#1682) * feat(fslib): add rmtempSync and rmtempPromise to xfs * perf(cli): perform async temp cleanup * chore: versions * Update packages/yarnpkg-fslib/sources/index.ts Co-authored-by: Maël Nison <nison.mael@gmail.com> * refactor: only unregister on success Co-authored-by: Maël Nison <nison.mael@gmail.com>

view details

push time in 3 days

delete branch yarnpkg/berry

delete branch : merceyz/temp-cleanup-perf

delete time in 3 days

PR merged yarnpkg/berry

perf(cli): perform async temp cleanup

What's the problem this PR addresses?

Yarn is cleaning up its temp folders in the exit event which forces us to use sync IO calls which has a performance impact.

How did you fix it?

Implemented rmtempPromise and call it right after the CLI is done and about to exit, where we can run async IO without problems.

Result

Time spent cleaning up temp folders after a install with a hot cache and lockfile (install-cache-and-lock in the benchmarks)

before after
Nextjs benchmark 326ms 25ms
Gatsby benchmark 654ms 20ms
Typescript Website 846ms 44ms

Benchmark workflow result: Before: https://github.com/yarnpkg/berry/actions/runs/200276519 After: https://github.com/yarnpkg/berry/actions/runs/200408519

Checklist

  • [x] I have read the Contributing Guide.
  • [x] I have set the packages that need to be released for my changes to be effective.
  • [x] I have verified that all automated PR checks pass.
+89 -27

0 comment

4 changed files

merceyz

pr closed time in 3 days

push eventyarnpkg/berry

Kristoffer K

commit sha 4ec25296c33445b5bdc3f74f59b938f08526bb69

perf(core): make check for cache entries async (#1685) * perf(core): make check for cache entries async * chore: remove false comment

view details

push time in 3 days

delete branch yarnpkg/berry

delete branch : merceyz/async-cache-check

delete time in 3 days

PR merged yarnpkg/berry

perf(core): make check for cache entries async

What's the problem this PR addresses?

When running fetchPackageFromCache Yarn checks if the file already exists using existsSync instead of existsPromise blocking the event loop.

How did you fix it?

Changed existsSync to existsPromise, however this caused race conditions (which lead to https://github.com/yarnpkg/berry/pull/1684) so I moved the load logic into loadPackageThroughMutex to make sure any part of the fetch for a specific locator is mutexed.

Result

When testing the gatsby benchmark install-cache-and-lock locally this reduces the time spent in fetchPackageFromCache from 1001ms to 393ms

Before: https://github.com/yarnpkg/berry/actions/runs/200598797 After: https://github.com/yarnpkg/berry/actions/runs/200603660

Checklist

  • [x] I have read the Contributing Guide.
  • [x] I have set the packages that need to be released for my changes to be effective.
  • [x] I have verified that all automated PR checks pass.
+64 -33

0 comment

2 changed files

merceyz

pr closed time in 3 days

pull request commentyarnpkg/berry

fix(plugin-compact) update fsevents patch to support virtual path

I really want to look but the diff is difficult to read due to the GH interface not working super well for diffs 😞 I'll try to improve a bit our patch infra tomorrow to store the changes under JS syntax, and reapply your diff on top of it.

missing1984

comment created time in 3 days

push eventyarnpkg/berry

Maël Nison

commit sha b071cbabb120025a6eb7df471523943d34de1b23

Fixes build execution (#1683) * Fixes build scripts trigger * Prefers not using deprecated * Removes debug * Fixes error messages on invalid package directories * Versions * Fixes path comparison

view details

push time in 3 days

delete branch yarnpkg/berry

delete branch : mael/train

delete time in 3 days

PR merged yarnpkg/berry

Fixes build execution

What's the problem this PR addresses?

  • A typo was causing incorrect build executions
  • The changelog was missing a few items (it still does)
  • The incorrect error message was printed when running Yarn from a non-workspace directory
  • Yarn wasn't differentiating deprecated versions from non-deprecated ones

How did you fix it?

  • Fixed the typo, added tests
  • Print a more helpful error message when Yarn is used on something that isn't a workspace
  • Deprecated versions won't be used if other versions satisfy the range

Checklist <!--- Don't worry if you miss something, chores are automatically tested. --> <!--- This checklist exists to help you remember doing the chores when you submit a PR. --> <!--- Put an x in all the boxes that apply. -->

<!-- See https://yarnpkg.com/advanced/contributing#preparing-your-pr-to-be-released for more details. --> <!-- Check with yarn version check and fix with yarn version check -i -->

  • [x] I have set the packages that need to be released for my changes to be effective.

<!-- The "Testing chores" workflow validates that your PR follows our guidelines. --> <!-- If it doesn't pass, click on it to see details as to what your PR might be missing. -->

  • [ ] I have verified that all automated PR checks pass.
+160 -8

0 comment

5 changed files

arcanis

pr closed time in 3 days

push eventyarnpkg/berry

Kristoffer K

commit sha 180e04593ab96a6fa6018bfbae24a0465ab5cc40

fix(core): only fetch unique locators (#1684)

view details

push time in 3 days

delete branch yarnpkg/berry

delete branch : merceyz/fetch-locator-once

delete time in 3 days

PR merged yarnpkg/berry

Reviewers
fix(core): only fetch unique locators

What's the problem this PR addresses?

During fetchEverything Yarn fetches the same locators multiple times wasting resources. Though the mutex prevents a full fetch.

How did you fix it?

Make fetchEverything only fetch unique locators, which also fixes the summary when the cache is empty to show No packages were cached - 1911 packages had to be fetched instead of 532 packages were already cached, 1911 had to be fetched

Result When run locally this improves the gatsby benchmark install-cache-and-lock, where there are 532 duplicated locators, by ~500ms.

Before: https://github.com/yarnpkg/berry/actions/runs/200437582 After: https://github.com/yarnpkg/berry/actions/runs/200511894

Checklist

  • [x] I have read the Contributing Guide.
  • [x] I have set the packages that need to be released for my changes to be effective.
  • [x] I have verified that all automated PR checks pass.
+43 -7

0 comment

2 changed files

merceyz

pr closed time in 3 days

Pull request review commentyarnpkg/berry

perf(core): make check for cache entries async

 export class Cache {     };      const loadPackageThroughMutex = async () => {-      const mutex = loadPackage();+      const mutexedLoad = async () => {+        // We don't yet know whether the cache path can be computed yet, since that+        // depends on whether the cache is actually the mirror or not, and whether+        // the checksum is known or not.+        const tentativeCachePath = this.getLocatorPath(locator, expectedChecksum);++        const cacheExists = tentativeCachePath !== null+          ? await baseFs.existsPromise(tentativeCachePath)+          : false;++        const action = cacheExists+          ? onHit+          : onMiss;++        // Note: must be synchronous, otherwise the mutex may break (a concurrent+        // execution may start while we're running the action)

That's not true anymore, since the mutex will be assigned in parallel of mutexedLoad. We can leave those callbacks sync, but better remove the comment.

merceyz

comment created time in 3 days

Pull request review commentyarnpkg/berry

perf(cli): perform async temp cleanup

 export type XFS = NodeFS & {    mktempPromise(): Promise<PortablePath>;   mktempPromise<T>(cb: (p: PortablePath) => Promise<T>): Promise<T>;++  /**+   * Unregisters and tries to remove all temp folders created by mktempSync and mktempPromise+   */+  rmtempPromise(): Promise<void>;++  /**+   * Unregisters and tries to remove all temp folders created by mktempSync and mktempPromise+   */+  rmtempSync(): void; };  const tmpdirs = new Set<PortablePath>();  let cleanExitRegistered = false;  function registerCleanExit() {-  if (!cleanExitRegistered)-    cleanExitRegistered = true;-  else+  if (cleanExitRegistered)     return; -  const cleanExit = () => {-    process.off(`exit`, cleanExit);--    for (const p of tmpdirs) {-      tmpdirs.delete(p);-      try {-        xfs.removeSync(p);-      } catch {-        // Too bad if there's an error-      }-    }-  };--  process.on(`exit`, cleanExit);+  cleanExitRegistered = true;+  process.once(`exit`, xfs.rmtempSync);

As a rule I prefer to always use explicit callbacks regardless of whether the arguments happen to be mostly compatible or not, to avoid the kind of problems you get with .map(something).

  process.once(`exit`, () => {
    xfs.rmtempSync();
  });
merceyz

comment created time in 3 days

Pull request review commentyarnpkg/berry

perf(cli): perform async temp cleanup

 export const xfs: XFS = Object.assign(new NodeFS(), {       }     }   },++  async rmtempPromise() {+    await Promise.all(Array.from(tmpdirs.values()).map(async p => {+      tmpdirs.delete(p);+      try {+        await xfs.removePromise(p, {maxRetries: 0});+      } catch {+        // Too bad if there's an error+      }+    }));+  },++  rmtempSync() {+    for (const p of tmpdirs) {+      tmpdirs.delete(p);

Same

merceyz

comment created time in 3 days

Pull request review commentyarnpkg/berry

perf(cli): perform async temp cleanup

 export const xfs: XFS = Object.assign(new NodeFS(), {       }     }   },++  async rmtempPromise() {+    await Promise.all(Array.from(tmpdirs.values()).map(async p => {+      tmpdirs.delete(p);

I'd move that after the xfs.removePromise. This way, even if it doesn't get removed right now, it might get removed once the program exits.

merceyz

comment created time in 3 days

push eventyarnpkg/berry

Maël Nison

commit sha 7b5603058e1a25437c95a2300ae05116e55a5fe0

Fixes path comparison

view details

push time in 3 days

Pull request review commentfacebook/jest

Add `.pnp.js` to `transformIgnorePatterns` defaults

 exports[`--showConfig outputs config info and exits 1`] = `         ]       ],       "transformIgnorePatterns": [-        "/node_modules/"+        "/node_modules/",+        "\\\\.pnp\\\\.c?js$"

There's .pnp.data.json under certain configurations, so better just use a wildcard

irudoy

comment created time in 3 days

Pull request review commentfacebook/jest

Add `.pnp.js` to `transformIgnorePatterns` defaults

 exports[`--showConfig outputs config info and exits 1`] = `         ]       ],       "transformIgnorePatterns": [-        "/node_modules/"+        "/node_modules/",+        "\\\\.pnp\\\\.c?js$"

There's .pnp.data.json under certain configurations, so better just use a wildcard

irudoy

comment created time in 3 days

issue closedyarnpkg/berry

[Bug] plugin-interactive-tools reports invalid latest package version

  • [ ] I'd be willing to implement a fix

Describe the bug

plugin-interactive-tools marks a deprecated version, not tagged as "latest", as "Range/Latest" and suggests updating to it.

The line presented to me in upgrade process:

? Pick the packages you want to upgrade.          Current          Range/Latest
 … 
 > @wojtekmaj/predict-input-value                 ◉  ^1.0.0        ◯  ^1.1.0

Quick look at npm api results for this package reveals that:

  • 1.1.0 is indeed highest version number, BUT
  • Tag "latest" is set to 1.0.0:
    "dist-tags": {
      "latest": "1.0.0"
    },
    
  • 1.1.0 is deprecated:
    "versions": {
      "1.1.0": {
        "name": "@wojtekmaj/predict-input-value",
        "version": "1.1.0",
        …
        "deprecated": "Mistakenly released"
      }
      "1.0.0": { … }
    },
    

To Reproduce

I hope the information above is enough, but let me know if you need even more information.

Environment if relevant (please complete the following information):

  • OS: [e.g. OSX, Linux, Windows, ...] macOS
  • Node version [e.g. 8.15.0, 10.15.1, ...] 14.5.0
  • Yarn version [e.g. 2.0.0-rc1, ...] 2.1.1

closed time in 4 days

wojtekmaj

issue commentyarnpkg/berry

[Bug] plugin-interactive-tools reports invalid latest package version

Should be fixed by https://github.com/yarnpkg/berry/pull/1683

wojtekmaj

comment created time in 4 days

issue closedyarnpkg/berry

[Bug] yarn install fails if casing is inconsistent for workspace directory

  • [ ] I'd be willing to implement a fix

Describe the bug

I am using yarn on Windows. This is the workspaces definition:

  "workspaces": [
    "packages/*",
    "mobile"
  ],

If the path listed is not an exact-case match to the current directory, then yarn install will fail with:

d:\git\Website\Mobile>yarn install
Usage Error: This command can only be run from within a workspace of your project (Mobile isn't a workspace of /d:/git/Website/package.json).

Windows treats paths as case-insensitive, so I would expect yarn to do so as well. This problem is exacerbated by the fact that if you use PowerShell as your shell, it lets you cd into a directory with any casing variant you want. (cmd, on the other hand, seems to always use the casing on disk regardless of what you type.)

To Reproduce

Create directory structure as follows:

\Test
   \packages
      \a
   \Mobile

Add a package.json to the root:

{
  "name": "test",
  "description": "test Monorepo",
  "private": true,
  "workspaces": [
    "packages/*",
    "mobile"
  ]
}

Add a basic package.json to the packages/a and Mobile directories.

Run yarn install from Mobile.

Environment if relevant (please complete the following information):

  • OS: Windows
  • Node version: 12.18.1
  • Yarn version 2.1.1

closed time in 4 days

dpolivy

issue commentyarnpkg/berry

[Bug] yarn install fails if casing is inconsistent for workspace directory

I think it's fine to be case-sensitive. Generally speaking, we try to enforce that projects are as portable as possible, and in this case there is very little benefits in supporting accesses through different path cases (similarly, if you run require('foo/PACKAGE.JSON'), it won't work under PnP even though it would have with node_modules).

That said there was a display issue - the error message we print should have been much more descriptive, but a bug was causing the incorrect one to be displayed. This will be fixed with https://github.com/yarnpkg/berry/pull/1683.

dpolivy

comment created time in 4 days

PR opened yarnpkg/berry

Fixes build execution

What's the problem this PR addresses?

  • A typo was causing incorrect build executions
  • The changelog was missing a few items (it still does)
  • The incorrect error message was printed when running Yarn from a non-workspace directory
  • Yarn wasn't differentiating deprecated versions from non-deprecated ones

How did you fix it?

  • Fixed the typo, added tests
  • Print a more helpful error message when Yarn is used on something that isn't a workspace
  • Deprecated versions won't be used if other versions satisfy the range

Checklist <!--- Don't worry if you miss something, chores are automatically tested. --> <!--- This checklist exists to help you remember doing the chores when you submit a PR. --> <!--- Put an x in all the boxes that apply. -->

<!-- See https://yarnpkg.com/advanced/contributing#preparing-your-pr-to-be-released for more details. --> <!-- Check with yarn version check and fix with yarn version check -i -->

  • [x] I have set the packages that need to be released for my changes to be effective.

<!-- The "Testing chores" workflow validates that your PR follows our guidelines. --> <!-- If it doesn't pass, click on it to see details as to what your PR might be missing. -->

  • [ ] I have verified that all automated PR checks pass.
+159 -8

0 comment

5 changed files

pr created time in 4 days

push eventyarnpkg/berry

Maël Nison

commit sha e3a7c660ebd2d06235eff5620397c339d8d3c4cb

Versions

view details

push time in 4 days

create barnchyarnpkg/berry

branch : mael/train

created branch time in 4 days

pull request commentyarnpkg/berry

fix(compat): add `promise-inflight` to extensions

Thanks!

ylemkimon

comment created time in 4 days

push eventyarnpkg/berry

ylemkimon

commit sha 5a605a4148c6f7719da2a67bb33348c9ad7044b3

fix(compat): add `promise-inflight` to extensions (#1680)

view details

push time in 4 days

PR merged yarnpkg/berry

fix(compat): add `promise-inflight` to extensions

What's the problem this PR addresses? <!-- Describe the rationale of your PR. --> <!-- Link all issues that it closes. (Closes/Resolves #xxxx.) -->

promise-inflight requires Bluebird, and then falls back to native Promise (https://git.io/JJP8d). However, Bluebird is not declared as peer dependencies. (https://github.com/iarna/promise-inflight/pull/4)

promise-inflight has 12M weekly downloads.

How did you fix it? <!-- A detailed description of your implementation. -->

Added promise-inflight to compat extensions.

Checklist <!--- Don't worry if you miss something, chores are automatically tested. --> <!--- This checklist exists to help you remember doing the chores when you submit a PR. --> <!--- Put an x in all the boxes that apply. -->

<!-- See https://yarnpkg.com/advanced/contributing#preparing-your-pr-to-be-released for more details. --> <!-- Check with yarn version check and fix with yarn version check -i -->

  • [x] I have set the packages that need to be released for my changes to be effective.

<!-- The "Testing chores" workflow validates that your PR follows our guidelines. --> <!-- If it doesn't pass, click on it to see details as to what your PR might be missing. -->

  • [x] I have verified that all automated PR checks pass.
+48 -5

0 comment

3 changed files

ylemkimon

pr closed time in 4 days

issue commentyarnpkg/berry

[Feature] add less verbose output

Which CI? We have a CI mode under which only a summary is printed. Perhaps your CI isn't well detected?

syabro

comment created time in 4 days

issue commentfacebook/jest

Test fails using yarn@berry and pnp-webpack-plugin

Curious - afaik Webpack 5 also simply requires pnpapi, I don't know why it would still be transpiled 🤔

irudoy

comment created time in 4 days

issue closedyarnpkg/berry

[Feature] add less verbose output

I don't like 100 YN0013 messages with can't be found in the cache and will be fetched from the remote registry

Can it be hidden somehow by default?

closed time in 4 days

syabro

issue commentyarnpkg/berry

[Feature] add less verbose output

Not reverted, and we don't have a regression as far as I'm aware. Feel free to open an issue with the relevant info (including screenshots, and potentially investigating yourself why would the logs be printed) if you believe this comes from Yarn.

syabro

comment created time in 4 days

issue commentfacebook/jest

Test fails using yarn@berry and pnp-webpack-plugin

That would be ideal! In fact, if you can ignore .pnp.* it would probably be the best - we'll likely change the file name to .pnp.cjs in the next major, otherwise it causes problem with projects configured for ESM.

irudoy

comment created time in 4 days

issue commentyarnpkg/berry

Individual lockfile per workspace

No (because the lockfile would effectively be pruned from extraneous entries, should it be persisted, so it wouldn't pass the immutable check) - I'd recommend to run the full yarn install --immutable as a CI validation step.

migueloller

comment created time in 5 days

issue commentyarnpkg/berry

[Feature] Preload `dependenciesMeta`

Reopening as we prefer to keep feature discussions in this repository, at least at the moment.

If I understand correctly, you'd like a list of packages with known "safe" postinstall scripts.

I think that's a fair request, and it almost certainly can be implemented in a plugin, but I don't think our org will take the responsibility of maintaining such a list - first because we would probably prefer to adopt a neutral point of view, but also because we simply don't have the bandwidth. Last reason, we are discouraging postinstall scripts altogether, and maintaining a list of "blessed packages" would got in the opposite way.

ylemkimon

comment created time in 5 days

IssuesEvent

pull request commentyarnpkg/rfcs

Preload `dependenciesMeta` for packages

Ah nevermind, I misunderstood your PR, you're talking about security, not compatibility. I'll close this RFC and reopen the issue to discuss it, as we don't really use this repository anymore.

ylemkimon

comment created time in 5 days

pull request commentyarnpkg/rfcs

Preload `dependenciesMeta` for packages

It's already the case! The compat plugin contains various builtin extensions - we just need to fill it more aggressively, but since we require to also send a PR upstream, it takes a bit of time that core maintainers don't always have:

https://github.com/yarnpkg/berry/blob/master/packages/plugin-compat/sources/extensions.ts

ylemkimon

comment created time in 5 days

issue commentyarnpkg/yarn

Why is this issue marked spam?

It's not locked as spam, though

dwjohnston

comment created time in 5 days

issue closedyarnpkg/yarn

Why is this issue marked spam?

https://github.com/yarnpkg/yarn/issues/4563

Googling an error arrived at what looks like the exact error described in the above issue.

The issue is opened, but locked as 'spam'. Is that a mistake?

It would be handy to be able to still discuss that issue.

closed time in 5 days

dwjohnston

issue commentfacebook/jest

Test fails using yarn@berry and pnp-webpack-plugin

Can't check right now, but I suspect babel-jest is transpiling the .pnp.js file, which it shouldn't do for the reason described in the error message. I'd suggest to try disabling transforms on this file.

irudoy

comment created time in 5 days

push eventyarnpkg/berry

Paul Soporan

commit sha 4b30624a284a1e08eb86b3129c72d94e2247819e

feat(fslib): improvements (#1675) * feat(fslib): improvements * fix(fslib): delete entry from fileSources when unregistering * Update packages/yarnpkg-fslib/sources/ZipOpenFS.ts Co-authored-by: Maël Nison <nison.mael@gmail.com> * Update packages/yarnpkg-fslib/sources/ZipOpenFS.ts Co-authored-by: Maël Nison <nison.mael@gmail.com> * Update packages/yarnpkg-fslib/sources/ZipFS.ts Co-authored-by: Maël Nison <nison.mael@gmail.com> * Update packages/yarnpkg-fslib/sources/ZipFS.ts Co-authored-by: Maël Nison <nison.mael@gmail.com> * refactor(fslib): make truncate len parameter optional Co-authored-by: Maël Nison <nison.mael@gmail.com>

view details

push time in 5 days

delete branch yarnpkg/berry

delete branch : paul/fslib-improvements

delete time in 5 days

PR merged yarnpkg/berry

Reviewers
feat(fslib): improvements

What's the problem this PR addresses? <!-- Describe the rationale of your PR. --> <!-- Link all issues that it closes. (Closes/Resolves #xxxx.) -->

  • ZipFS doesn't currently support read after write.
  • truncate isn't currently implemented
  • link isn't currently implemented
  • chown isn't currently implemented
  • It's hard to tell apart libzip errors from regular errors

How did you fix it? <!-- A detailed description of your implementation. -->

  • I've added a file source cache, which makes read-after-write operations completely bypass libzip
  • I've implemented truncate (also in ZipFS)
  • I've implemented link (not in ZipFS, since Zip archives don't support hardlinks. I think a solution would be to fully mock the behavior of hardlinks while having the hardlinked files stored on disk once for each entry. Is this a good idea?)
  • I've implemented chown (not in ZipFS, I can't think of any way to implement it there. Any ideas?)
  • Libzip errors are now special: they have a Libzip Error name and a code (e.g. ZIP_ER_CHANGED). I've also made ZipFS throw Assertion failed: unexpected libzip error when it encounters ZIP_ER_CHANGED since it should now be impossible for that to happen.

Checklist <!--- Don't worry if you miss something, chores are automatically tested. --> <!--- This checklist exists to help you remember doing the chores when you submit a PR. --> <!--- Put an x in all the boxes that apply. -->

<!-- See https://yarnpkg.com/advanced/contributing#preparing-your-pr-to-be-released for more details. --> <!-- Check with yarn version check and fix with yarn version check -i -->

  • [x] I have set the packages that need to be released for my changes to be effective.

<!-- The "Testing chores" workflow validates that your PR follows our guidelines. --> <!-- If it doesn't pass, click on it to see details as to what your PR might be missing. -->

  • [ ] I have verified that all automated PR checks pass.
+891 -204

0 comment

19 changed files

paul-soporan

pr closed time in 5 days

Pull request review commentyarnpkg/berry

feat(fslib): improvements

 export class ZipFS extends BasePortableFakeFS {     if (typeof index === `undefined`)       throw errors.EINVAL(`rmdir '${p}'`); -    this.libzip.delete(this.zip, index);     this.unregisterEntry(resolvedP);++    const rc = this.libzip.delete(this.zip, index);+    if (rc === -1) {+      throw this.makeLibzipError(this.libzip.getError(this.zip));+    }   }    private hydrateDirectory(resolvedP: PortablePath) {     const index = this.libzip.dir.add(this.zip, ppath.relative(PortablePath.root, resolvedP));     if (index === -1)-      throw new Error(this.libzip.error.strerror(this.libzip.getError(this.zip)));+      throw this.makeLibzipError(this.libzip.getError(this.zip));      this.registerListing(resolvedP);     this.registerEntry(resolvedP, index);      return index;   } +  async linkPromise(existingP: PortablePath, newP: PortablePath) {+    return this.linkSync(existingP, newP);+  }++  linkSync(existingP: PortablePath, newP: PortablePath) {+    // Zip archives don't support hard links:+    // https://stackoverflow.com/questions/8859616/are-hard-links-possible-within-a-zip-archive+    throw errors.EOPNOTSUPP(`link '${existingP}' -> '${newP}'`);

I agree with this semantic 👍 Not sure about hardlinks support though - they are very different, as changing one won't change the other. A code expecting a hardlink to work could get really weird bugs 🤔

paul-soporan

comment created time in 5 days

issue commentyarnpkg/berry

Clarify third party plugins distribution model and usage of builder / `yarn plugin import`

The first issue is how to distribute the plugin to the users. People just do git clone and yarn install and expect everything to be ready. Now we will expect them to do another step as well: yarn plugin import https://xxxxx/plugin.js.

Note that plugins are meant to be checked-in (same as the Yarn binary itself), so cloning is all that's required to have a working environment.

abdes

comment created time in 6 days

Pull request review commentyarnpkg/berry

feat(fslib): improvements

 export abstract class FakeFS<P extends Path> {   abstract readlinkPromise(p: P): Promise<P>;   abstract readlinkSync(p: P): P; +  abstract truncatePromise(p: P, len: number): Promise<void>;+  abstract truncateSync(p: P, len: number): void;

There are a few other implementations where len must be made optional

paul-soporan

comment created time in 6 days

Pull request review commentyarnpkg/berry

feat(fslib): improvements

 export class ZipFS extends BasePortableFakeFS {     return entry;   } +  async truncatePromise(p: PortablePath, len: number) {
  async truncatePromise(p: PortablePath, len: number = 0) {
paul-soporan

comment created time in 6 days

Pull request review commentyarnpkg/berry

feat(fslib): improvements

 export class ZipOpenFS extends BasePortableFakeFS {     });   } +  async truncatePromise(p: PortablePath, len: number) {
  async truncatePromise(p: PortablePath, len?: number) {
paul-soporan

comment created time in 6 days

Pull request review commentyarnpkg/berry

feat(fslib): improvements

 export class ZipFS extends BasePortableFakeFS {     if (typeof index === `undefined`)       throw errors.EINVAL(`rmdir '${p}'`); -    this.libzip.delete(this.zip, index);     this.unregisterEntry(resolvedP);++    const rc = this.libzip.delete(this.zip, index);+    if (rc === -1) {+      throw this.makeLibzipError(this.libzip.getError(this.zip));+    }   }    private hydrateDirectory(resolvedP: PortablePath) {     const index = this.libzip.dir.add(this.zip, ppath.relative(PortablePath.root, resolvedP));     if (index === -1)-      throw new Error(this.libzip.error.strerror(this.libzip.getError(this.zip)));+      throw this.makeLibzipError(this.libzip.getError(this.zip));      this.registerListing(resolvedP);     this.registerEntry(resolvedP, index);      return index;   } +  async linkPromise(existingP: PortablePath, newP: PortablePath) {+    return this.linkSync(existingP, newP);+  }++  linkSync(existingP: PortablePath, newP: PortablePath) {+    // Zip archives don't support hard links:+    // https://stackoverflow.com/questions/8859616/are-hard-links-possible-within-a-zip-archive+    throw errors.EOPNOTSUPP(`link '${existingP}' -> '${newP}'`);

I used ENOSYS for other "not implemented" errors, is there a reference for when to use EOPNOTSUPP?

paul-soporan

comment created time in 6 days

Pull request review commentyarnpkg/berry

feat(fslib): improvements

 export class ZipFS extends BasePortableFakeFS {     return entry;   } +  async truncatePromise(p: PortablePath, len: number) {+    const resolvedP = this.resolveFilename(`open '${p}'`, p);++    const index = this.entries.get(resolvedP);+    if (typeof index === `undefined`)+      throw errors.EINVAL(`open '${p}'`);++    const source = await this.getFileSource(index, {asyncDecompress: true});++    const truncated = Buffer.alloc(len, 0x00);+    source.copy(truncated);++    return await this.writeFilePromise(p, truncated);+  }++  truncateSync(p: PortablePath, len: number) {
  truncateSync(p: PortablePath, len: number = 0) {
paul-soporan

comment created time in 6 days

Pull request review commentyarnpkg/berry

feat(fslib): improvements

 export class ZipOpenFS extends BasePortableFakeFS {     });   } +  async truncatePromise(p: PortablePath, len: number) {+    return await this.makeCallPromise(p, async () => {+      return await this.baseFs.truncatePromise(p, len);+    }, async (zipFs, {subPath}) => {+      return await zipFs.truncatePromise(subPath, len);+    });+  }++  truncateSync(p: PortablePath, len: number) {
  truncateSync(p: PortablePath, len?: number) {
paul-soporan

comment created time in 6 days

push eventyarnpkg/berry

Paul Soporan

commit sha 5e237a348b95a6258449629c1967b4f028081502

fix(fslib): fix copyPromise mkdir overwrite (#1674) * fix(fslib): fix copyPromise mkdir overwrite * refactor: use pathUtils.dirname * chore: update pnp hook

view details

push time in 6 days

delete branch yarnpkg/berry

delete branch : paul/fix/copyPromise/overwrite

delete time in 6 days

PR merged yarnpkg/berry

Reviewers
fix(fslib): fix copyPromise mkdir overwrite

What's the problem this PR addresses? <!-- Describe the rationale of your PR. --> <!-- Link all issues that it closes. (Closes/Resolves #xxxx.) -->

https://github.com/yarnpkg/berry/pull/1597 switched all mkdirp calls to mkdir(?, {recursive: true}) to improve performance, but didn't take into account that there's an important difference between the 2 functions: mkdirp doesn't throw if a non-folder basename already exists, while mkdir(?, {recursive: true}) does.

This problem caused all cross-drive movePromise calls (in other words, all cross-drive mirror-to-cache moves) to throw if the destination already existed.

How did you fix it? <!-- A detailed description of your implementation. -->

I made it so that mkdir(?, {recursive: true}) EEXIST errors are ignored inside copyPromise.

I also added a test.

Checklist <!--- Don't worry if you miss something, chores are automatically tested. --> <!--- This checklist exists to help you remember doing the chores when you submit a PR. --> <!--- Put an x in all the boxes that apply. -->

<!-- See https://yarnpkg.com/advanced/contributing#preparing-your-pr-to-be-released for more details. --> <!-- Check with yarn version check and fix with yarn version check -i -->

  • [x] I have set the packages that need to be released for my changes to be effective.

<!-- The "Testing chores" workflow validates that your PR follows our guidelines. --> <!-- If it doesn't pass, click on it to see details as to what your PR might be missing. -->

  • [x] I have verified that all automated PR checks pass.
+94 -14

1 comment

7 changed files

paul-soporan

pr closed time in 6 days

pull request commentyarnpkg/berry

feat(plugin-file): make file: protocol update cache when folder changes

Really nice! That file: never updated always was a pain 😃

paul-soporan

comment created time in 6 days

push eventyarnpkg/berry

Paul Soporan

commit sha 405af59e06f0da96b7c6dbf2a2d1efe9197e5f82

feat(plugin-file): make file: protocol update cache when folder changes (#1612) * feat(plugin-file): make file: protocol update cache when folder changes * refactor: remove non-null assertion * fix(plugin-essentials): fix `yarn add <path>` * chore: update versions * chore: fix errors * refactor: fix error * fix: fix zip archive encoding Co-authored-by: Maël Nison <nison.mael@gmail.com> * refactor: refactor fileUtils functions Co-authored-by: Maël Nison <nison.mael@gmail.com> * refactor: add comment explaining why binding the descriptor is necessary * refactor: move archive buffer generation to memory * refactor: resolve path relative to cwd * refactor: don't normalize absolute paths Co-authored-by: Maël Nison <nison.mael@gmail.com>

view details

push time in 6 days

delete branch yarnpkg/berry

delete branch : paul/feat/file-update-cache

delete time in 6 days

PR merged yarnpkg/berry

Reviewers
feat(plugin-file): make file: protocol update cache when folder changes

What's the problem this PR addresses? <!-- Describe the rationale of your PR. --> <!-- Link all issues that it closes. (Closes/Resolves #xxxx.) -->

Packages referenced using the file: protocol don't update their cache entry when their contents change.

How did you fix it? <!-- A detailed description of your implementation. -->

I made the checksum of the archive a part of the file: locator, which makes it automatically update the cache entry when changed.

Checklist <!--- Don't worry if you miss something, chores are automatically tested. --> <!--- This checklist exists to help you remember doing the chores when you submit a PR. --> <!--- Put an x in all the boxes that apply. -->

<!-- See https://yarnpkg.com/advanced/contributing#preparing-your-pr-to-be-released for more details. --> <!-- Check with yarn version check and fix with yarn version check -i -->

  • [x] I have set the packages that need to be released for my changes to be effective.

<!-- The "Testing chores" workflow validates that your PR follows our guidelines. --> <!-- If it doesn't pass, click on it to see details as to what your PR might be missing. -->

  • [ ] I have verified that all automated PR checks pass.
+221 -61

0 comment

11 changed files

paul-soporan

pr closed time in 6 days

issue closedyarnpkg/berry

Quick question regarding "--ignore-scripts"

Hi,

I've tried to use the new version of yarn with the --ignore-scripts. This flag has been removed from the v2. Why though? I've always found it to be a little bit of a security layer when installing any script/package. Is this on purpose? Will it ever come back again? Or it's something that has been deemed as unnecessary and no longer will be supported?

Would love to know about this, when you have the time. All-in-all keep up the good work! 💪

closed time in 6 days

radical-edo

issue commentyarnpkg/berry

Quick question regarding "--ignore-scripts"

Generally speaking, a lot of command line flags have been moved to the configuration settings. For example, --ignore-scripts is now available as enableScripts.

The reason for this is that those flags were defining persistent behaviors (ie things that you want to apply to every install, not just a single one), so they were ill-suited to CLI options (for example, running yarn add would also trigger an install, so you had to remember to add the --ignore-scripts flag ... who did it?).

radical-edo

comment created time in 6 days

issue commentyarnpkg/berry

Clarify third party plugins distribution model and usage of builder / `yarn plugin import`

  • I'm not sure why you want to have both a plugin and a package - I'd suggest to avoid that and simply include everything into the plugin. If you want to have a package to use it with other package managers too, imo you should just bundle it inside the plugin (the builder will do this) and just distribute the Yarn plugin to users.

  • I'd also avoid the postinstall and the unplug. I don't know how many statics you have, but with the current single-file model you'd rather bundle the assets inside the JS - it's a bit weird, I agree, but usually there aren't that many images within plugins 😄

abdes

comment created time in 6 days

issue commentyarnpkg/berry

Clarify third party plugins distribution model and usage of builder / `yarn plugin import`

It remains however a bit unclear in the current documentation and in the current behavior of yarnpkg-builder how this feature fits into the larger ecosystem

That's true! It's because we didn't put much thought into that yet 😅

Given the already large number of changes in the v2, we preferred to implement low-level tools and figure out the next high-level layers based on community feedback during the next months. Plugins are one of those things that are a bit rough at the moment until we can figure out a better user story.

builder build plugin always normalizes the plugin name to '@yarnpkg/xxxxx'. It's not clear today if this is intended or if there is something more that we need to know,

It's intended...ish. The normalization was made so that people could in theory override the builtin plugins (like essentials) with their own implementations. In practice I'm not sure it works, and I'm even less sure it's a valid use case. I'd be ok with removing this limitation.

yarn plugin import has different treatment depending on whether the plugin is hosted on yarnpkg repo or not. If not, it has to be a downloadable single file bundle. Why we can't just ship third-party plugins as npm modules, add them as dev deps, and then yarn can just import from there, like usual?

Because, just like the Yarn bundle itself, plugins cannot have dependencies (chicken and egg problem; if you have dependencies you need to run an install, but to run an install you need the plugins to be registered).

So I figured the easiest way to distribute them would be as single JS files (just like the regular CLI), and thus using the npm registry didn't really provide anything of value (since you need to download a tgz which may contain many files).

even when a plugin is imported from the local filesystem, yarn plugin import builds a different cjs file. Not clear how is that working with builder and if we (as plugin developers) need to know about it.

Not sure what you mean - iirc we just copy it into the local directory and add it to the configuration.

abdes

comment created time in 6 days

issue commentyarnpkg/berry

[Feature] Reconsider hoisting strategy in node-modules linker mode

On a separate note, if you want safety in linking nm, I think you're looking for a similar algorithm to the one used by pnpm - not nohoist. I'd be very interested to see that implemented in Yarn, although someone would have to take ownership of its implementation.

darthtrevino

comment created time in 6 days

issue commentyarnpkg/berry

[Feature] Add flag to `yarn upgrade-interactive` to just show new packages

I agree it could be improved - if someone wants to give a PR a try, go for it!

schickling

comment created time in 6 days

issue commentyarnpkg/berry

[Feature] Reconsider hoisting strategy in node-modules linker mode

The main point of the nm linker is to make the migration from Yarn 1 to Yarn 2 easier, for people who can't switch to PnP yet. For this to be true, we cannot make semi-large changes like this... for now.

Yarn will keep having major releases (more frequently than before, likely one per year), so I'm open to revisit this in one of them, depending how far in the migration process we are.

For now, however, the nm linker must be as low friction as possible.

darthtrevino

comment created time in 6 days

issue commentyarnpkg/yarn

Command line revamp

Fwiw we have since then started to use Clipanion.

arcanis

comment created time in 7 days

create barncharcanis/parcel

branch : mael/events-dep

created branch time in 7 days

PR opened parcel-bundler/parcel

Adds the missing events dep

↪️ Pull Request

The latest release is missing a dependency, so tests are failing: https://github.com/yarnpkg/berry/runs/947729059?check_suite_focus=true

✔️ PR Todo

  • [ ] Added/updated unit tests for this change
  • [ ] Filled out test instructions (In case there aren't any unit tests)
  • [x] Included links to related issues/PRs
+1 -0

0 comment

1 changed file

pr created time in 7 days

Pull request review commentnetlify/build-image

Fix support for Yarn 2 (berry)

 run_yarn() {     export PATH=$NETLIFY_CACHE_DIR/yarn/bin:$PATH   fi +  yarn_version=$(yarn --version) -  echo "Installing NPM modules using Yarn version $(yarn --version)"++  echo "Installing NPM modules using Yarn version $yarn_version"   run_npm_set_temp -  # Remove the cache-folder flag if the user set any.+  local yarn_local="$YARN_FLAGS"+   # We want to control where to put the cache   # to be able to store it internally after the build.-  local yarn_local="${YARN_FLAGS/--cache-folder * /}"-  # The previous pattern doesn't match the end of the string.-  # This removes the flag from the end of the string.-  yarn_local="${yarn_local%--cache-folder *}"+  if [[ "${yarn_version%%.*}" -gt "1" ]]+  then+    # The cache-folder flag is deprecated in Yarn 2+    # Override the environment variable if the user set any.+    export YARN_GLOBAL_FOLDER="$NETLIFY_BUILD_BASE/.yarn_cache"+    export YARN_ENABLE_GLOBAL_CACHE=1

I'm not a fan of using environment variables for this, because it'll break people using zero-installs (when the cache is inside the repository), overriding the config they explicitly requested (I know it's what the code already did, overriding --cache-folder etc, but that really strikes me as a bad idea).

I think a more gentle approach would be to create a .yarnrc.yml file in the home directory that would contain the "default options" you want to have. This way, users would still be able to opt-out of the default workflow to use their own.

ylemkimon

comment created time in 7 days

Pull request review commentnetlify/build-image

Fix support for Yarn 2 (berry)

 run_yarn() {   fi   restore_home_cache ".yarn_cache" "yarn cache" -  if [ $(which yarn) ] && [ "$(yarn --version)" != "$yarn_version" ]+  # Check the version of yarn installed globally+  if [ $(which yarn) ] && [ "$(YARN_IGNORE_PATH=1 yarn --version)" != "$yarn_version" ]   then     echo "Found yarn version ($(yarn --version)) that doesn't match expected ($yarn_version)"
    echo "Global yarn version ($(yarn --version)) that doesn't match expected ($yarn_version)"
ylemkimon

comment created time in 7 days

push eventarcanis/pmm

Maël Nison

commit sha 757110995e8b1dd87af904a8851d58096b07673d

Update README.md

view details

push time in 7 days

push eventarcanis/pmm

Maël Nison

commit sha f8198bf5041e65713b29dffdb8f003e2b9f85047

Update build.yml

view details

push time in 7 days

push eventarcanis/pmm

Maël Nison

commit sha 81f081362bc6c246554be59178cd87b5813bf192

Update build.yml

view details

push time in 7 days

push eventarcanis/pmm

Maël Nison

commit sha 5c27730f8467c3ff249309455719f9b5def15975

Fixes artifact path

view details

push time in 7 days

push eventarcanis/pmm

Maël Nison

commit sha faa261a3727bf73b49ae3373a1d37723d5ae49b9

Commits the change temporarily

view details

push time in 7 days

more