dart pub get --no-dev-dependencies

[dcharkes]

We have the following repository structure:

• pkgs/
  • my_package/
  • some_package/
  • lints_for_this_repo/ (used by analysis_options in the top two packages)
  • tools_for_this_repo/ (used in the tool/ by the top two packages)

I don't want to publish lints_for_this_repo and tools_for_this_repo, they are just for the repository, not for the larger Dart eco system.

On most use cases using dev path dependencies (either directly, or via a pub workspace) is fine:

• git clone you'll have the other packages at the paths.
• pub get with my_package will not require lints_for_this_repo.

However, there are use cases in a package might be downloaded from pub in a script, and that script then does pub get. This use case is not supported, because the dev dependencies don't exist on pub or on the path.

• [hooks_runner] Remove package_graph.json fallback native#2266 (comment)

Should we consider having a dart pub get --no-dev-dependencies?

Or should we make a best practice that someone should publish unlisted packages for these use cases such as your own custom lints and tools?

[sigurdm]

One workaround for some use cases is to make a "dummy" package with a single (path) dependency on the downloaded package. That is in principle how eg. pub global activate works.

[dcharkes]

One workaround for some use cases is to make a "dummy" package with a single (path) dependency on the downloaded package. That is in principle how eg. pub global activate works.

That does indeed only pub get non-dev dependencies. 😆 So we have at least two use cases. 👍

[sigurdm]

Can you explain your use case in more detail? Why do you want to download a package from pub in a script and do pub get?

[dcharkes]

Can you explain your use case in more detail? Why do you want to download a package from pub in a script and do pub get?

cc @mosuem

[mosuem]

There is a breaking API check done in PR health checks via the https://github.com/bmw-tech/dart_apitool, which compares the API of the latest published version of a package to the one in a PR.

This needs to analyze the API of a package downloaded from pub.

cc @devmil

[sigurdm]

We have before discussed some kind of "production" mode of pub get before.
I should

• ignore the surrounding workspace
• find the transitive closure on don-dev dependencies of the single current package, and
• download those if needed
• Error if any content-hash is invalid or a version cannot be retrieved (ie. imply --enforce-lockfile).

I think we have always punted it because you can do the workaround above. But I think it is a meaningful thing to do in many cases.

@jonasfj WDYT?

[jonasfj]

This needs to analyze the API of a package downloaded from pub.

That doesn't mean you need to download the package from pub.dev and run pub get inside it.

You make a dummy package that depends on the target package, then resolve the dummy package and run the analyzer in said context.

---

Problem with --no-dev-dependencies is that tools like dart test and dart analyze should run pub get implicitly -- and then the --no-dev-dependencies disappears.

---

For dart_apitool it's probably better to make a dummy root package that depends on the target package, and then resolve the dummy root package using pub get.

For running tools we have pub global acticate/run, and we should improve how it works, but "running a package globally" is probably the thing we want.

Thus, I could question if we even need a "production" mode, because you should build AOT and then use the binary in production.