Not all package managers are respected

[moltar]

It looks like only yarn and npm are handled, but pnpm (and others) are not.

oclif/src/tarballs/build.ts

Lines 70 to 99 in 3570d93

	const addDependencies = async () => {
	const yarnRoot = findYarnWorkspaceRoot(c.root) || c.root
	if (existsSync(path.join(yarnRoot, 'yarn.lock'))) {
	await copy(path.join(yarnRoot, 'yarn.lock'), path.join(c.workspace(), 'yarn.lock'))
	const {stdout} = await exec('yarn -v')
	const yarnVersion = stdout.charAt(0)
	if (yarnVersion === '1') {
	await exec('yarn --no-progress --production --non-interactive', {cwd: c.workspace()})
	} else if (yarnVersion === '2') {
	throw new Error('Yarn 2 is not supported yet. Try using Yarn 1, or Yarn 3')
	} else {
	try {
	await exec('yarn workspaces focus --production', {cwd: c.workspace()})
	} catch (error: unknown) {
	if (error instanceof Error && error.message.includes('Command not found')) {
	throw new Error('Missing workspace tools. Run `yarn plugin import workspace-tools`.')
	}
	throw error
	}
	}
	} else {
	const lockpath = existsSync(path.join(c.root, 'package-lock.json'))
	? path.join(c.root, 'package-lock.json')
	: path.join(c.root, 'npm-shrinkwrap.json')
	await copy(lockpath, path.join(c.workspace(), path.basename(lockpath)))
	await exec('npm install --production', {cwd: c.workspace()})
	}
	}

Related:

• Release error for pnpm workspace. #1170
• Bug: Oclif pack does not work on Yarn v3 #759

I think this should be solved with a proper interface that each package manager solution can implement.

[mdonnalley]

@moltar I agree that this should support pnpm but I don't think we have the bandwidth at the present moment to implement a solution. However, we'll take a PR if you need a solution now and it's something you're willing to take on.

[moltar]

Would you accept the use of this dependency? https://www.npmjs.com/package/detect-package-manager

[mdonnalley]

Would you accept the use of this dependency? https://www.npmjs.com/package/detect-package-manager

Yeah looks fine to me

[ericis]

Would you accept the use of this dependency? https://www.npmjs.com/package/detect-package-manager

This doesn't appear to respect the "package.json" packageManager setting.

Example:

"packageManager": "yarn@4.0.2",

For background, we attempted to change an oclif CLI implementation embedded as a subdirectory of a monorepo with pnpm at its root. For a while, the only option was to simply have pnpm ignore the oclif directory contents entirely and to use the classic yarn v1 in the oclif project. Recently, while testing an upgrade to yarn v4, we refactored the base monorepo to yarn as well and abandoned pnpm simply because switching was unnecessary friction and, while pnpm is awesome, there wasn't enough justification not to use yarn instead and make the whole thing work consistently. *We still had to configure yarn to use classic mode by setting the file ".yarnrc.yml" with the following:

# IMPORTANT: oclif expects classic dependencies
nodeLinker: node-modules
nmHoistingLimits: dependencies

[kurtaking]

Would you accept the use of this dependency? https://www.npmjs.com/package/detect-package-manager

This doesn't appear to respect the "package.json" packageManager setting.

Example:

"packageManager": "yarn@4.0.2",

For background, we attempted to change an oclif CLI implementation embedded as a subdirectory of a monorepo with pnpm at its root. For a while, the only option was to simply have pnpm ignore the oclif directory contents entirely and to use the classic yarn v1 in the oclif project. Recently, while testing an upgrade to yarn v4, we refactored the base monorepo to yarn as well and abandoned pnpm simply because switching was unnecessary friction and, while pnpm is awesome, there wasn't enough justification not to use yarn instead and make the whole thing work consistently. *We still had to configure yarn to use classic mode by setting the file ".yarnrc.yml" with the following:

# IMPORTANT: oclif expects classic dependencies
nodeLinker: node-modules
nmHoistingLimits: dependencies

Hey @ericis, could you provide insight into how you handle yarn workspace dependencies when running oclif pack tarballs?

'dependencies': {
  'example-pkg': 'workspace:^'
}

And does your monorepo have a single .yarnrc.yml file at the root with nmHoistingLimits: dependencies or is that only defined in your version of the packages/cli?

[ericis]

@kurtaking I'll take a look. I am fairly certain we abandoned any OS-specific installs along with tarball packaging in favor of publishing the CLI to a private node registry and simply encouraging the use of NodeJS, project-specific dependencies that pin the version required and in exceptional cases to install globally (yarn global add ...) and/or use something like npx ... for single use. Last I looked, we were also looking at wrapping it in an OCI-compatible container to avoid specific runtime dependencies (e.g. node) and only require any OCI-compatible runner.

[kurtaking]

@kurtaking I'll take a look. I am fairly certain we abandoned any OS-specific installs along with tarball packaging in favor of publishing the CLI to a private node registry and simply encouraging the use of NodeJS, project-specific dependencies that pin the version required and in exceptional cases to install globally (yarn global add ...) and/or use something like npx ... for single use. Last I looked, we were also looking at wrapping it in an OCI-compatible container to avoid specific runtime dependencies (e.g. node) and only require any OCI-compatible runner.

That's fair. I'm also not having issues with the yarn workspace and publishing the cli to our registry.

Running yarn oclif pack tarballs from the root of the workspace doesn't work because the cli is located at packages/cli.

Running yarn oclif pack tarballs in packages/cli isn't working because yarn has not resolved the 'example-pkg': 'workspace:^'-style dependencies.

It's been a pain to figure out with my current knowledge, but we can't abandon OS-specific installs right now.