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

Extracting package name from pubspec.yaml #19

Open
martingeorgiu opened this issue Apr 5, 2024 · 6 comments
Open

Extracting package name from pubspec.yaml #19

martingeorgiu opened this issue Apr 5, 2024 · 6 comments
Assignees

Comments

@martingeorgiu
Copy link
Collaborator

Is there a reason why the --package is required when the imports are in form of package:?

I was thinking that if in the --path there is pubspec.yaml, we can extract the package name directly from there. Then the parameter could be useful and used only when the --path leads to a folder where there is no pubspec.yaml.

@polina-c
Copy link
Owner

polina-c commented Apr 5, 2024

The original assumption was that most projects use the lint https://dart.dev/tools/linter-rules/prefer_relative_imports
So, this parameter is needed for very rare set of projects.

What you suggested makes sense, but feels as something that is easily breakable by updated format of pubspec.yaml in future versions of dart/flutter.

But may be I am wrong. Feel free to put together PR that implements it. I will review and merge it :)

@martingeorgiu
Copy link
Collaborator Author

We use lint collection lint, which is quite popular, especially for being so strict, and there is used the exact opposite, i.e. always_use_package_imports. To be honest, I don't have any strong preference, but I like how lint package is curated, so I stick to most of its rules and I would say most of the lint users do the same.

So, I would say this is not only for some rare projects. However, I'm also not fond of linking directly to pubspec.yaml notation, but I don't know any other way. If you aren't against it or have a better solution, I would create a PR in the coming weeks once I have time for that.

@polina-c
Copy link
Owner

polina-c commented Apr 8, 2024

Thank you for explaining. Sure, feel free to go ahead with the PR. I will review it.

@polina-c
Copy link
Owner

polina-c commented Aug 4, 2024

Implemented.
Thank you @martingeorgiu

@polina-c polina-c closed this as completed Aug 4, 2024
@martingeorgiu
Copy link
Collaborator Author

Did you push/publish it @polina-c? I can't find it anywhere

@polina-c
Copy link
Owner

polina-c commented Aug 6, 2024

Oh, i mixed it with something else. Reopening. Thanks for the catch.🌤

@polina-c polina-c reopened this Aug 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants