helloadhavan/github_issues huggingface dataset:
Repository: vuejs/vue
Pull request: fix(test): change model text's priority case

<!--
Please make sure to read the Pull Request Guidelines:
https://github.com/vuejs/vue/blob/dev/.github/CONTRIBUTING.md#pull-request-guidelines
-->

<!-- PULL REQUEST TEMPLATE -->
<!-- (Update "[ ]" to "[x]" to check a box) -->

**What kind of change does this PR introduce?** (check at least one)

- [ ] Bugfix
- [ ] Feature
- [ ] Code style update
- [ ] Refactor
- [ ] Build-related changes
- [x] Other, please describe:

**Does this PR introduce a breaking change?** (check one)

- [ ] Yes
- [x] No

If yes, please describe the impact and migration path for existing applications:

**The PR fulfills these requirements:**

- [x] It's submitted to the `dev` branch for v2.x (or to a previous version branch), _not_ the `master` branch
- [ ] When resolving a specific issue, it's referenced in the PR's title (e.g. `fix #xxx[,#xxx]`, where "xxx" is the issue number)
- [x] All tests are passing: https://github.com/vuejs/vue/blob/dev/.github/CONTRIBUTING.md#development-setup
- [ ] New/updated tests are included

If adding a **new feature**, the PR's description includes:
- [ ] A convincing reason for adding this feature (to avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it)

**Other information:**
I think the intention of this test case is to prove v-model's event is handled before other v-on events. i tried to revert code associated with this test and it passed. so original one seems to fail to prove that (correct me if i am wrong).

Changed files:
filename: test/unit/features/directives/model-text.spec.js
patch: @@ -238,7 +238,7 @@ describe('Directive v-model text', () => {
       template: '<input v-model="a" @input="onInput">',
       methods: {
         onInput (e) {
-          spy(e.target.value)
+          spy(this.a)
         }
       }
     }).$mount()
Repository: huggingface/transformers
Pull request: fix crash in when running FSDP2+TP


- distributed: @3outeille @ArthurZucker


Changed files:
filename: src/transformers/trainer.py
patch: @@ -2333,11 +2333,7 @@ def _inner_training_loop(
         if use_accelerator_prepare:
             self.model.train()
             if hasattr(self.lr_scheduler, "step"):
-                # We should avoid accelerate preparing the model in TP case since we dont need it as it is handled by transformers from_pretrained and also it goes into DDP based preparation.
-                if self.is_tp_enabled:
-                    self.optimizer = self.accelerator.prepare(self.optimizer)
-                else:
-                    model, self.optimizer = self.accelerator.prepare(self.model, self.optimizer)
+                model, self.optimizer = self.accelerator.prepare(self.model, self.optimizer)
             else:
                 # to handle cases wherein we pass "DummyScheduler" such as when it is specified in DeepSpeed config.
                 model, self.optimizer, self.lr_scheduler = self.accelerator.prepare(
@@ -5101,7 +5097,8 @@ def create_accelerator_and_postprocess(self):
                         args["parallelism_config"] = ParallelismConfig(tp_size=self.model.tp_size)
                 else:
                     raise ValueError("Requires accelerate>1.12.0 to use Tensor Parallelism.")
-
+            elif args["parallelism_config"].tp_size != self.model.tp_size:
+                args["parallelism_config"].tp_size = self.model.tp_size
         if is_accelerate_available("1.2.0"):
             # it we don't have the correct version, we will rely on env var instead that were set in TrainingArguments
             from accelerate.utils import TorchDynamoPlugin
Repository: ollama/ollama
Pull request: add QwQ model to supported list

Add QwQ model (32B, 20GB) to the downloadable models table in README.md

Changed files:
filename: README.md
patch: @@ -54,6 +54,7 @@ Here are some example models that can be downloaded:
 
 | Model              | Parameters | Size  | Download                         |
 | ------------------ | ---------- | ----- | -------------------------------- |
+| QwQ                | 32B        | 20GB  | `ollama run qwq`                 |
 | DeepSeek-R1        | 7B         | 4.7GB | `ollama run deepseek-r1`         |
 | DeepSeek-R1        | 671B       | 404GB | `ollama run deepseek-r1:671b`    |
 | Llama 3.3          | 70B        | 43GB  | `ollama run llama3.3`            |
Repository: vuejs/vue
Pull request: fix(lifecycle): beforeUpdated should not be called if component is de…

…stroyed, fix #8076

<!--
Please make sure to read the Pull Request Guidelines:
https://github.com/vuejs/vue/blob/dev/.github/CONTRIBUTING.md#pull-request-guidelines
-->

<!-- PULL REQUEST TEMPLATE -->
<!-- (Update "[ ]" to "[x]" to check a box) -->

**What kind of change does this PR introduce?** (check at least one)

- [X] Bugfix
- [ ] Feature
- [ ] Code style update
- [ ] Refactor
- [ ] Build-related changes
- [ ] Other, please describe:

**Does this PR introduce a breaking change?** (check one)

- [ ] Yes
- [X] No

If yes, please describe the impact and migration path for existing applications:

**The PR fulfills these requirements:**

- [X] It's submitted to the `dev` branch for v2.x (or to a previous version branch), _not_ the `master` branch
- [X] When resolving a specific issue, it's referenced in the PR's title (e.g. `fix #xxx[,#xxx]`, where "xxx" is the issue number)
- [X] All tests are passing: https://github.com/vuejs/vue/blob/dev/.github/CONTRIBUTING.md#development-setup
- [X] New/updated tests are included

If adding a **new feature**, the PR's description includes:
- [ ] A convincing reason for adding this feature (to avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it)

**Other information:**
This properly fixes #8076 since PR #8381 did not cover beforeUpdate.

Changed files:
filename: src/core/instance/lifecycle.js
patch: @@ -196,7 +196,7 @@ export function mountComponent (
   // component's mounted hook), which relies on vm._watcher being already defined
   new Watcher(vm, updateComponent, noop, {
     before () {
-      if (vm._isMounted) {
+      if (vm._isMounted && !vm._isDestroyed) {
         callHook(vm, 'beforeUpdate')
       }
     }

filename: test/unit/features/options/lifecycle.spec.js
patch: @@ -152,6 +152,43 @@ describe('Options lifecycle hooks', () => {
         expect(vm.$el.textContent).toBe('bar!')
       }).then(done)
     })
+
+    // #8076
+    it('should not be called after destroy', done => {
+      const beforeUpdate = jasmine.createSpy('beforeUpdate')
+      const destroyed = jasmine.createSpy('destroyed')
+
+      Vue.component('todo', {
+        template: '<div>{{todo.done}}</div>',
+        props: ['todo'],
+        destroyed,
+        beforeUpdate
+      })
+
+      const vm = new Vue({
+        template: `
+          <div>
+            <todo v-for="t in pendingTodos" :todo="t" :key="t.id"></todo>
+          </div>
+        `,
+        data () {
+          return {
+            todos: [{ id: 1, done: false }]
+          }
+        },
+        computed: {
+          pendingTodos () {
+            return this.todos.filter(t => !t.done)
+          }
+        }
+      }).$mount()
+
+      vm.todos[0].done = true
+      waitForUpdate(() => {
+        expect(destroyed).toHaveBeenCalled()
+        expect(beforeUpdate).not.toHaveBeenCalled()
+      }).then(done)
+    })
   })
 
   describe('updated', () => {
Repository: vercel/next.js
Pull request: Apply `buildArgs` also for deploy tests (via `package.json`)

This change ensures that the `buildArgs` specified in `nextTestSetup` are also applied when running deploy tests. This is achieved by modifying the build command in the `package.json` file used for deploy tests to include the specified `buildArgs`.

See also https://vercel.com/docs/builds/configure-a-build#build-command.

The only current e2e test that uses the `buildArgs` option is `test/e2e/react-compiler/react-compiler.test.ts`, but that one is excluded from deploy tests via `deploy-tests-manifest.json`.

Changed files:
filename: test/lib/next-modes/base.ts
patch: @@ -281,6 +281,9 @@ export class NextInstance {
                   ...pkgScripts,
                   build:
                     (pkgScripts['build'] || this.buildCommand || 'next build') +
+                    (this.buildArgs?.length
+                      ? ` ${this.buildArgs.join(' ')}`
+                      : '') +
                     ' && pnpm post-build',
                 },
               },

filename: test/production/app-dir/build-output-prerender/build-output-prerender.test.ts
patch: @@ -3,7 +3,6 @@ import path from 'path'
 const { version: nextVersion } = require('next/package.json')
 
 const cacheComponentsEnabled = process.env.__NEXT_CACHE_COMPONENTS === 'true'
-
 const pprEnabled = process.env.__NEXT_EXPERIMENTAL_PPR === 'true'
 
 describe('build-output-prerender', () => {

filename: test/production/app-dir/no-mangling/no-mangling.test.ts
patch: @@ -16,7 +16,7 @@ describe('no-mangling', () => {
 
       expect(next.cliOutput).toInclude(`
 Error: Kaputt!
-    at `) // mangled function name omitted because it's undeterministic
+    at `) // mangled function name omitted because it's not deterministic
 
       // `Page` is the original function name that is mangled because `next
       // build` was called without `--no-mangling`.
Repository: nodejs/node
Pull request: tools: update nixpkgs-unstable to 16c7794d0a28b5a37904d55bcca36003b91

This is an automated update of nixpkgs-unstable to 16c7794d0a28b5a37904d55bcca36003b91.

Changed files:
filename: tools/nix/pkgs.nix
patch: @@ -1,10 +1,10 @@
 arg:
 let
   repo = "https://github.com/NixOS/nixpkgs";
-  rev = "3edc4a30ed3903fdf6f90c837f961fa6b49582d1";
+  rev = "16c7794d0a28b5a37904d55bcca36003b9109aaa";
   nixpkgs = import (builtins.fetchTarball {
     url = "${repo}/archive/${rev}.tar.gz";
-    sha256 = "0ajsdd3m4qz8mpimfcrawx81cqj8s5ypnkrxpwy7icj9j8gcpksa";
+    sha256 = "1931vmgdclk332ikh7psxha1bskvrjwqrqm8a3xwcsr5hc8jfmbw";
   }) arg;
 in
 nixpkgs
Repository: vuejs/vue
Pull request: fix(weex): support data class type that is string (#9124)

<!--
Please make sure to read the Pull Request Guidelines:
https://github.com/vuejs/vue/blob/dev/.github/CONTRIBUTING.md#pull-request-guidelines
-->

<!-- PULL REQUEST TEMPLATE -->
<!-- (Update "[ ]" to "[x]" to check a box) -->

**What kind of change does this PR introduce?** (check at least one)

- [x] Bugfix
- [ ] Feature
- [ ] Code style update
- [ ] Refactor
- [ ] Build-related changes
- [ ] Other, please describe:

**Does this PR introduce a breaking change?** (check one)

- [ ] Yes
- [x] No

If yes, please describe the impact and migration path for existing applications:

**The PR fulfills these requirements:**

- [x] It's submitted to the `dev` branch for v2.x (or to a previous version branch), _not_ the `master` branch
- [x] When resolving a specific issue, it's referenced in the PR's title (e.g. `fix #xxx[,#xxx]`, where "xxx" is the issue number)
- [x] All tests are passing: https://github.com/vuejs/vue/blob/dev/.github/CONTRIBUTING.md#development-setup
- [ ] New/updated tests are included

If adding a **new feature**, the PR's description includes:
- [ ] A convincing reason for adding this feature (to avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it)

**Other information:**


Changed files:
filename: src/platforms/weex/runtime/modules/class.js
patch: @@ -44,6 +44,8 @@ function makeClassList (data: VNodeData): Array<string> {
     classList.push.apply(classList, dataClass)
   } else if (isObject(dataClass)) {
     classList.push.apply(classList, Object.keys(dataClass).filter(className => dataClass[className]))
+  } else if (typeof dataClass === 'string') {
+    classList.push.apply(classList, dataClass.trim().split(/\s+/))
   }
   return classList
 }
Repository: electron/electron
Pull request: fix: second argument to `shell.writeShortcutLink` is optional

Backport of #49476

See that PR for details.


Notes: Fixed an issue where `shell.writeShortcutLink` was throwing `TypeError: Insufficient number of arguments` when called with just `[(path, options)]`.


Changed files:
filename: shell/common/api/electron_api_shell.cc
patch: @@ -111,11 +111,20 @@ bool WriteShortcutLink(const base::FilePath& shortcut_path,
                        gin_helper::Arguments* args) {
   base::win::ShortcutOperation operation =
       base::win::ShortcutOperation::kCreateAlways;
-  args->GetNext(&operation);
-  auto options = gin::Dictionary::CreateEmpty(args->isolate());
-  if (!args->GetNext(&options)) {
-    args->ThrowError();
-    return false;
+  gin::Dictionary options = gin::Dictionary::CreateEmpty(args->isolate());
+
+  v8::Local<v8::Value> peek = args->PeekNext();
+  if (peek->IsObject()) {
+    if (!args->GetNext(&options)) {
+      args->ThrowError();
+      return false;
+    }
+  } else {
+    args->GetNext(&operation);
+    if (!args->GetNext(&options)) {
+      args->ThrowError();
+      return false;
+    }
   }
 
   base::win::ShortcutProperties properties;

filename: spec/api-shell-spec.ts
patch: @@ -172,6 +172,16 @@ describe('shell module', () => {
       expect(fs.existsSync(tmpShortcut)).to.be.true();
     });
 
+    it('writes the shortcut with omitted operation (defaults to create)', () => {
+      expect(shell.writeShortcutLink(tmpShortcut, shortcutOptions)).to.be.true();
+      expect(fs.existsSync(tmpShortcut)).to.be.true();
+      expect(shell.readShortcutLink(tmpShortcut)).to.deep.equal(shortcutOptions);
+
+      const newOptions = { ...shortcutOptions, description: 'new description' };
+      expect(shell.writeShortcutLink(tmpShortcut, newOptions)).to.be.true();
+      expect(shell.readShortcutLink(tmpShortcut)).to.deep.equal(newOptions);
+    });
+
     it('correctly sets the fields', () => {
       expect(shell.writeShortcutLink(tmpShortcut, shortcutOptions)).to.be.true();
       expect(shell.readShortcutLink(tmpShortcut)).to.deep.equal(shortcutOptions);
Repository: vuejs/vue
Pull request: fix(types): avoid `this` in VueConstructor signature

- [x] Bugfix
- [ ] Feature
- [ ] Code style update
- [ ] Refactor
- [ ] Build-related changes
- [ ] Other, please describe:

**Does this PR introduce a breaking change?** (check one)

- [ ] Yes
- [x] No

If yes, please describe the impact and migration path for existing applications:

**The PR fulfills these requirements:**

- [x] It's submitted to the `dev` branch for v2.x (or to a previous version branch), _not_ the `master` branch
- [x] When resolving a specific issue, it's referenced in the PR's title (e.g. `fix #xxx[,#xxx]`, where "xxx" is the issue number)
- [x] All tests are passing: https://github.com/vuejs/vue/blob/dev/.github/CONTRIBUTING.md#development-setup
- [ ] New/updated tests are included

**Other information:**

Fix https://github.com/vuejs/vue-class-component/issues/294

Mixing `this`, `interface`, `extends` and `new` signature seems to be hairy in TypeScript. It is better to not rely on `this`.


Changed files:
filename: types/test/tsconfig.json
patch: @@ -1,6 +1,7 @@
 {
   "compilerOptions": {
     "target": "es5",
+    "experimentalDecorators": true,
     "lib": [
       "dom",
       "es2015"

filename: types/test/vue-test.ts
patch: @@ -102,10 +102,10 @@ class Test extends Vue {
     this.compile("<div>{{ message }}</div>");
     this
       .use(() => {
-        
+
       })
       .use(() => {
-        
+
       })
       .mixin({})
       .mixin({});
@@ -193,3 +193,10 @@ Vue.extend({
     return h('canvas', {}, [a])
   }
 })
+
+declare function decorate<VC extends typeof Vue>(v: VC): VC;
+
+@decorate
+class Decorated extends Vue {
+  a = 123;
+}

filename: types/vue.d.ts
patch: @@ -111,9 +111,9 @@ export interface VueConstructor<V extends Vue = Vue> {
   component<Props>(id: string, definition: FunctionalComponentOptions<Props, RecordPropsDefinition<Props>>): ExtendedVue<V, {}, {}, {}, Props>;
   component(id: string, definition?: ComponentOptions<V>): ExtendedVue<V, {}, {}, {}, {}>;
 
-  use<T>(plugin: PluginObject<T> | PluginFunction<T>, options?: T): this;
-  use(plugin: PluginObject<any> | PluginFunction<any>, ...options: any[]): this;
-  mixin(mixin: VueConstructor | ComponentOptions<Vue>): this;
+  use<T>(plugin: PluginObject<T> | PluginFunction<T>, options?: T): VueConstructor<V>;
+  use(plugin: PluginObject<any> | PluginFunction<any>, ...options: any[]): VueConstructor<V>;
+  mixin(mixin: VueConstructor | ComponentOptions<Vue>): VueConstructor<V>;
   compile(template: string): {
     render(createElement: typeof Vue.prototype.$createElement): VNode;
     staticRenderFns: (() => VNode)[];
Repository: vercel/next.js
Pull request: [ci] Enable Turborepo remote caching in e2e release deploy tests

E2E deploy release tests do not run with our self-hosted runners which have the tokens for Turborepo hardcoded. Without remote caching, we'll fetch the latest test timings on every run. This means that retries will not have the same sharding/ordering of tests i.e. retries don't retry and test different tests.

We now expose the Turbo token via GitHub secrets.

Part of https://linear.app/vercel/issue/NAR-719/

## Test plan

- [x] deploy tests on this branch run with remote caching: https://github.com/vercel/next.js/actions/runs/21143971117/job/60804882995#step:31:42
- [x] existing build_and_test still uses remote caching: https://github.com/vercel/next.js/actions/runs/21143919092/job/60805221344?pr=88746#step:29:34

Changed files:
filename: .github/workflows/build_reusable.yml
patch: @@ -97,6 +97,7 @@ env:
 
   TURBO_TEAM: 'vercel'
   TURBO_CACHE: 'remote:rw'
+  TURBO_TOKEN: ${{ secrets.TURBO_TOKEN }}
 
   NEXT_TELEMETRY_DISABLED: 1
   # allow not skipping install-native postinstall script if we don't have a binary available already

filename: .github/workflows/test_e2e_deploy_release.yml
patch: @@ -21,8 +21,6 @@ on:
         type: string
 
 env:
-  TURBO_TEAM: 'vercel'
-  TURBO_CACHE: 'remote:rw'
   VERCEL_TEST_TEAM: vtest314-next-e2e-tests
   VERCEL_TEST_TOKEN: ${{ secrets.VERCEL_TEST_TOKEN }}
   DATADOG_API_KEY: ${{ secrets.DATA_DOG_API_KEY }}
Repository: ggml-org/llama.cpp
Pull request: common : update completion executables list [no ci]

This commit updates the bash completion executables list, adding missing executables and removing some that non longer exist.

Changed files:
filename: common/arg.cpp
patch: @@ -732,23 +732,28 @@ static void common_params_print_completion(common_params_context & ctx_arg) {
         "llama-completion",
         "llama-convert-llama2c-to-ggml",
         "llama-cvector-generator",
+        "llama-debug",
+        "llama-diffusion-cli",
         "llama-embedding",
         "llama-eval-callback",
         "llama-export-lora",
+        "llama-finetune",
+        "llama-fit-params",
+        "llama-gemma3-cli",
         "llama-gen-docs",
         "llama-gguf",
         "llama-gguf-hash",
         "llama-gguf-split",
-        "llama-gritlm",
+        "llama-idle",
         "llama-imatrix",
-        "llama-infill",
-        "llama-mtmd-cli",
-        "llama-llava-clip-quantize-cli",
+        "llama-llava-cli",
         "llama-lookahead",
         "llama-lookup",
         "llama-lookup-create",
         "llama-lookup-merge",
         "llama-lookup-stats",
+        "llama-minicpmv-cli",
+        "llama-mtmd-cli",
         "llama-parallel",
         "llama-passkey",
         "llama-perplexity",
Repository: facebook/react
Pull request: [Flight] Simulate fetch to third party in fixture

This adds some I/O to go get the third party thing to test how it overlaps.

With #33482, this is what it looks like. The await gets cut off when the third party component starts rendering. I.e. after the latency to start.

<img width="735" alt="Screenshot 2025-06-08 at 5 42 46 PM" src="https://github.com/user-attachments/assets/f68d9a84-05a1-4125-b3f0-8f3e4eaaa5c1" />

This doesn't fully simulate everything because it should actually also simulate each chunk of the stream coming back too. We could wrap the ReadableStream to simulate that. In that scenario, it would probably get some awaits on the chunks at the end too.

Changed files:
filename: fixtures/flight/src/App.js
patch: @@ -43,7 +43,7 @@ async function Bar({children}) {
 }
 
 async function ThirdPartyComponent() {
-  return delay('hello from a 3rd party', 30);
+  return await delay('hello from a 3rd party', 30);
 }
 
 let cachedThirdPartyStream;
@@ -52,16 +52,35 @@ let cachedThirdPartyStream;
 // That way it gets the owner from the call to createFromNodeStream.
 const thirdPartyComponent = <ThirdPartyComponent />;
 
-function fetchThirdParty(noCache) {
+function simulateFetch(cb, latencyMs) {
+  return new Promise(resolve => {
+    // Request latency
+    setTimeout(() => {
+      const result = cb();
+      // Response latency
+      setTimeout(() => {
+        resolve(result);
+      }, latencyMs);
+    }, latencyMs);
+  });
+}
+
+async function fetchThirdParty(noCache) {
   // We're using the Web Streams APIs for tee'ing convenience.
-  const stream =
-    cachedThirdPartyStream && !noCache
-      ? cachedThirdPartyStream
-      : renderToReadableStream(
+  let stream;
+  if (cachedThirdPartyStream && !noCache) {
+    stream = cachedThirdPartyStream;
+  } else {
+    stream = await simulateFetch(
+      () =>
+        renderToReadableStream(
           thirdPartyComponent,
           {},
           {environmentName: 'third-party'}
-        );
+        ),
+      25
+    );
+  }
 
   const [stream1, stream2] = stream.tee();
   cachedThirdPartyStream = stream1;
Repository: nodejs/node
Pull request: esm: avoid throw when module specifier is not url

This particular exception is responsible for a lot of overhead when debugging with large esm codebases with VS Code and break on caught exceptions is enabled.

VS Code silently suppresses this exception, but the mechanism it uses to do so is a bit slow so avoiding this common exception can speed up loading of esm code.

In my scenario (running a single test from a [particular test suite](https://github.com/microsoft/FluidFramework/tree/main/packages/dds/tree/src/test) un VS Code's debugger) this saved over half of the total run time (over 20 seconds) bring the runtime from over 40 seconds to around 17 (Timing isn't too consistent as it hits a bunch of exceptions I have to continue through along the way).

This should also make debugging without suppression of this exception more pleasant in other tools such as the Chrome dev tools when attached to NodeJs processes.


This is my first attempt at contributing to NodeJS, so I don't know the conventions here very well. If it is the case that this codebase prefers the approach of throwing and catching exceptions in cases like these, and thus does not want to do this change to benefit a specific usage pattern by a third-party tool, that is understandable and, in that case, feel free to just close this PR. This change was simply so easy that it was easier to just propose it as a PR than to ask if this kind of change would be accepted.

Changed files:
filename: lib/internal/modules/esm/resolve.js
patch: @@ -42,6 +42,7 @@ const {
   ERR_INVALID_MODULE_SPECIFIER,
   ERR_INVALID_PACKAGE_CONFIG,
   ERR_INVALID_PACKAGE_TARGET,
+  ERR_INVALID_URL,
   ERR_MODULE_NOT_FOUND,
   ERR_PACKAGE_IMPORT_NOT_DEFINED,
   ERR_PACKAGE_PATH_NOT_EXPORTED,
@@ -846,12 +847,13 @@ function moduleResolve(specifier, base, conditions, preserveSymlinks) {
   } else if (protocol === 'file:' && specifier[0] === '#') {
     resolved = packageImportsResolve(specifier, base, conditions);
   } else {
-    try {
-      resolved = new URL(specifier);
-    } catch (cause) {
+    const url = URLParse(specifier);
+    if (url !== null) {
+      resolved = url;
+    } else {
       if (isData && !BuiltinModule.canBeRequiredWithoutScheme(specifier)) {
         const error = new ERR_UNSUPPORTED_RESOLVE_REQUEST(specifier, base);
-        setOwnProperty(error, 'cause', cause);
+        setOwnProperty(error, 'cause', new ERR_INVALID_URL(specifier));
         throw error;
       }
       resolved = packageResolve(specifier, base, conditions);