# shareStrategy

- Type: `'version-first' | 'loaded-first'`
- Required: No
- Default: `'version-first'` (set by webpack plugin/bundler runtime)

Control the loading strategy of shared dependencies:

- `'version-first'`: Version priority, ensuring that the highest version of shared dependencies is used. **All remotes entry files will be automatically loaded during initialization** to register shared dependencies and ensure version compatibility. This strategy is recommended when there are strict version requirements.

- `'loaded-first'`: Prioritize reuse of already loaded shared dependencies. Remotes are loaded on-demand rather than during initialization. This strategy is recommended when you want to reuse loaded dependencies for performance.

:::warning Offline Remote Considerations

The `'version-first'` strategy automatically loads remote entry files during application startup to initialize shared dependencies. If any remote is offline or unreachable, this will trigger the `errorLoadRemote` hook with `lifecycle: 'beforeLoadShare'` during startup. Without proper error handling, this can cause application initialization failures.

The `'loaded-first'` strategy defers remote loading until modules are actually requested, which means offline remotes only cause failures when those specific remotes are accessed, not during application startup.

**What happens with version-first and offline remotes:**

1. During initialization, remotes are loaded via `initializeSharing()`
2. If remote manifest/entry is offline, `module.getEntry()` fails
3. `errorLoadRemote` hook is called with `lifecycle: 'beforeLoadShare'`
4. If no fallback is provided, the initialization may hang or fail

**Required error handling for version-first:**

```ts
const plugin = {
  name: 'offline-resilient-plugin',
  errorLoadRemote(args) {
    if (args.lifecycle === 'beforeLoadShare') {
      // Handle version-first offline remote during startup
      return {
        init: () => Promise.resolve(),
        get: (module) => () => Promise.resolve(() => 'Offline Fallback')
      };
    }
  }
};
```

For production applications with potential network issues, consider:

- Using `'loaded-first'` strategy for better resilience
- Implementing comprehensive error handling for `'beforeLoadShare'` lifecycle
- Adding retry mechanisms via plugins
- Using proper error boundaries and fallback components

See [Error Load Remote Solutions](/blog/error-load-remote.md) for detailed offline handling strategies.

:::