Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: monorepoOnly option #23

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

feat: monorepoOnly option #23

wants to merge 2 commits into from

Conversation

benmccann
Copy link
Collaborator

Description

A new option to only return the package manager if we're located in a monorepo

Linked Issues

n/a

Additional context

Need this for the Svelte CLI

/**
* Only detect the package manager if within a monorepo
*/
monorepoOnly?: boolean
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel it reads a bit confusing. Do you mean at monorepo root, or just inside a monorepo? And that would be the expected behaviour when it's not?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean just inside a monorepo

The issue I'm trying to solve here is that we've gotten several bug reports when setting up new Svelte projects where people unknowingly have a package.lock or yarn.lock in a parent directory and it detects those files and chooses the package manager based off of them, but it's not actually what the user wants. If we're setting up a new project within a monorepo then we want to pay attention to what's there, but otherwise we want to ignore it

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe instead you could provide a rootDir that we stop looking for lock files up?

people unknowingly have a package.lock or yarn.lock in a parent directory

Which to me, it seems to be a mistake they should fix on their side. Or is there any valid usage of that?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe instead you could provide a rootDir that we stop looking for lock files up?

We wouldn't know the rootDir as it's the user's project. We would copy the code from this PR to find the root dir. Or we could change this PR to provide a utility method to find whether there's a monorepo root

Which to me, it seems to be a mistake they should fix on their side. Or is there any valid usage of that?

It is a mistake. But one that happens with annoying frequency and causes us to get bug reports I'd rather avoid

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants