import type { ComponentID } from '@teambit/component-id'; import { ComponentIdList } from '@teambit/component-id'; import type { IssuesList } from '@teambit/component-issues'; import type { ConsumerComponent as Component } from '@teambit/legacy.consumer-component'; import { Dependency } from '@teambit/legacy.consumer-component'; import type { Workspace } from '@teambit/workspace'; import type { DependencyResolverMain } from '@teambit/dependency-resolver'; import type { Consumer } from '@teambit/legacy.consumer'; import type { Logger } from '@teambit/logger'; import OverridesDependencies from './overrides-dependencies'; import { DependenciesData } from './dependencies-data'; import type { DebugDependencies } from './auto-detect-deps'; export type AllDependencies = { dependencies: Dependency[]; devDependencies: Dependency[]; peerDependencies: Dependency[]; }; export type AllPackagesDependencies = { packageDependencies: Record; devPackageDependencies: Record; peerPackageDependencies: Record; }; export declare class ApplyOverrides { private component; private depsResolver; private logger; private workspace?; componentId: ComponentID; componentFromModel: Component | undefined; allDependencies: AllDependencies; allPackagesDependencies: AllPackagesDependencies; /** * This will store a copy of the package deps before removal * in order to apply auto detected rules that are running after the removal */ originAllPackagesDependencies: AllPackagesDependencies; issues: IssuesList; coreAspects: string[]; processedFiles: string[]; overridesDependencies: OverridesDependencies; debugDependenciesData: DebugDependencies; /** * see workspace.getAutoDetectOverrides docs. * these overrides are from env/variants/merge-config. not ones with "force: true". */ autoDetectOverrides: Record | undefined; /** * outside a workspace, when the dependencies are calculated from a new policy (e.g. a lane merge from a bare scope): * the components that a workspace would have in its .bitmap, e.g. the components of the lane. * a workspace takes the version of a component dependency from a forced policy, the .bitmap or the installed package * (see updateDependenciesVersions). a scope has no .bitmap and no node_modules, so when this is set, the versions of * the policy are applied here. otherwise, a component dependency keeps its version. */ workspaceComponentIds?: ComponentIdList; constructor(component: Component, depsResolver: DependencyResolverMain, logger: Logger, workspace?: Workspace | undefined); private setOverridesDependencies; private getEnvExtendsDeps; /** * This function is aim to solve the following case: * I have env1 extends env2 in my workspace * env1 is tagged with env2@1.0.0 in the model * env2 is in the workspace policy with version 2.0.0 * the node_modules is empty so env2@2.0.0 is missing * Without this change, we will get the env2@1.0.0 from the model * Then we will take the deps from its resolved env.jsonc * instead of takeing those of v2.0.0 * This function fixing this issue * @param deps * @returns */ private updateVersionOfMissingsInEnvJsonc; private getOverridesData; get consumer(): Consumer | undefined; getDependenciesData(): Promise<{ dependenciesData: DependenciesData; overridesDependencies: OverridesDependencies; autoDetectOverrides?: Record; }>; /** * Given the tree of file dependencies from the driver, find the components of these files. * Each dependency file has a path, use bit.map to search for the component name by that path. * If the component is found, add it to "this.allDependencies.dependencies". Otherwise, add it to "this.issues.untrackedDependencies". * * For the found components, add their sourceRelativePath and destinationRelativePath, they are being used for * generating links upon import: * sourceRelativePath - location of the link file. * destinationRelativePath - destination written inside the link file. * * When a dependency is found in a regular (implementation) file, it goes to `dependencies`. If * it found on a test file, it goes to `devDependencies`. * Similarly, when a package is found in a regular file, it goes to `packageDependencies`. When * if found in a test file, it goes to `devPackageDependencies`. * An exception for the above is when a package is required in a regular or test file but is also * mentioned in the `package.json` file as a peerDependency, in that case, the package is added * to `peerPackageDependencies` and removed from other places. Unless this package is overridden * and marked as ignored in the consumer or component config file. */ private populateDependencies; private removeIgnoredComponentsByOverrides; private loadAutoDetectOverrides; private cloneAllPackagesDependencies; private removeIgnoredPackagesByOverrides; private _resolvePackageData; private _getComponentIdToAdd; /** * the scope side of resolveFromOverrides() in updateDependenciesVersions(): a forced policy sets the version of a * component dependency. the version of an env's own dependency on a workspace component follows the workspace. */ private getComponentIdFromForcedVersion; /** * the scope side of the installed version in updateDependenciesVersions(): a workspace installs a component peer in * the range of the policy, and records the installed version. so when the version is out of the range, it's changed * to the version of the range. (when it's in the range, it's kept, as a workspace that has it installed would do) */ private setComponentPeerVersionInRange; private setVersionFromConfig; private findComponentDepByPackageName; getDependenciesToAddManually(packageJson: Record | null | undefined, existingDependencies: AllDependencies): { components: Record; packages: Record; } | undefined; private manuallyAddDependencies; /** * The function `removeCompDepsFromPackages` removes component dependencies from different package dependency fields * based on certain conditions. */ private removeCompDepsFromPackages; /** * Remove the dependencies which appear both in dev and regular deps from the dev * Because if a dependency is both dev dependency and regular dependency it should be treated as regular one * Apply for both packages and components dependencies */ private removeDevAndEnvDepsIfTheyAlsoRegulars; private applyPeersFromComponentModel; private applyPackageJson; private applyWorkspacePolicy; /** * It removes the @teambit/legacy dependency from the dependencies/devDeps and adds it as a peer dependency with ^. */ private makeLegacyAsPeer; private applyAutoDetectOverridesOnComponent; private getMissingPackagesFromIssues; private isPackageAutoDetected; private applyAutoDetectedOverrideForPackage; /** * Handle peer dependency specific logic. * @returns true if the package should be skipped (not added to dependencies) */ private handlePeerDependencyOverride; private removePackageFromAllDependencyTypes; private applyPackageVersion; private applyAutoDetectedPeersFromEnvOnEnvItSelf; /** * in the env.jsonc file, a policy-peer package can have `+` sign (or `+^`/`+~`) in the version. it means that it should be resolved * from the workspace. whatever version is installed/imported in the workspace, it should be used here. * in some cases, the package is not installed in the workspace, for example, the env is now imported without the * dep. so the dep is not in the node_modules. * strategy should be: .bitmap, workspace.jsonc, then model. * it's not in .bitmap, otherwise, it was linked and `_resolvePackageData` would have found it. * so either, it's in the workspace.jsonc or in the model. * @param preferWorkspacePolicy check the workspace.jsonc before what's installed. needed for a package that the * component gets with a plus version. what's installed for the component was installed according to the version it * had before, so it doesn't follow an upgrade in the workspace.jsonc (e.g. by "bit update"). */ private resolveEnvPeerDepVersion; /** * returns `package.json` of the component when it's imported, or `package.json` of the workspace * when it's authored. */ private _getPackageJson; private _getPackageJsonFromComponentModel; private setLegacyInsideHarmonyIssue; private _pkgFieldMapping; }