@anthonyshew I kind of disagree here. Perhaps LFS specifically is out of scope of for turbo, but the only way we can get affected turbo files is a bit hacky.

We ended up creating this action.yaml file:

name: Download LFS Files
description: Download LFS files for a specific package deployment.

inputs:
  package:
    description: The name of the package to deploy.
    required: true

runs:
  using: composite
  steps:
    - name: Download necessary LFS files
      shell: bash
      run: |
        # Get list of full LFS-tracked file paths
        lfsFiles=$(git lfs ls-files -n | xargs -n1 basename | sort)

        # Get all files needed by the package
        neededFiles=$(npx turbo run deploy:${{ env.VERCEL_ENV }} -F ${{ inputs.package }}... --dry=json \
          | jq -r '.tasks[].inputs | keys[]' | xargs -n1 basename | sort)

        # Find intersection of LFS files and needed files
        matchedLfsFiles=$(comm -12 <(echo "$lfsFiles") <(echo "$neededFiles"))

        if [ -z "$matchedLfsFiles" ]; then
          echo "No LFS files to download. Skipping 'git lfs pull'."
        else
          echo "::group::LFS files to download"
          echo "$matchedLfsFiles"
          echo "::endgroup::"

          git lfs pull --include="$(echo "$matchedLfsFiles" | paste -sd, -)"
        fi

I think at the very least having a cleaner way to get affected files is something that turbo could own. This part:

# Get all files needed by the package
neededFiles=$(npx turbo run deploy:${{ env.VERCEL_ENV }} -F ${{ inputs.package }}... --dry=json \
  | jq -r '.tasks[].inputs | keys[]' | xargs -n1 basename | sort)

This could easily be a turbo command instead of having to hack/parse json. We could have a command like:

turbo ls-files deploy -F @myrepo/app1...

That would be a much cleaner solution.

I still have a few hesitations:

• The usage of Git LFS described above is highly inadvisable and doesn't feel like a problem that Turborepo should be solving. I can say with near-100% certainty that a blob store (Vercel Blob, S3, etc.) should be used for this instead, which would obviate the need for this feature.
• I'm struggling to think of other use cases where this would be valuable. We haven't seen evidence of a similar need for a feature like this, so its difficult to justify prioritizing this work to get it added to Turborepo. Can you demonstrate concrete, broader use cases for this? Examples?
  • Assuming the broader need for this remains theoretical, I would say that handling this edge case using the code above is reasonable.

One more thing that I'll add is that asking colleagues/friends to brigade a post with upvotes isn't the best way to help us prioritize features. This post had 7 👍 reactions only an hour or so after posting, and I know that that wasn't organic due to the nature of the problem described. I know I've mentioned that we do look at 👍 reactions as one of our indicators of community interest, but this only helps if the reactions are an honest representation of the broader community.

@anthonyshew regarding Vercel Blob:

The use case for LFS is that we have a large number of apps using static images for websites and such. In CI, we don't want to waste time cloning those files to run something like a lint script. Those files are only needed for deployment. My understanding is that it is better to use repo-hosted static image files rather than an external storage like Vercel Blob or S3 for things like images on a website page.

As for other use cases, getting a list of file inputs to check/compare against diffs in the case of not having turbo remote caching set up is a good use case. If you wanted to side-step turbo caching you could use a list of input files and compare against diff from your main branch using such a tool (related discussion: #10324 (comment)).

I think the --dry API is almost good enough for most use cases.
If Turbo added a bit more clarity for it by just improved docs or more information or something, people could more easily build richer tools like turbo-fetch-lfs or dependency analyzers without needing official support for every niche.
In the end, we managed to achieve exactly what we wanted by utilizing a broader api structure, even though it was not clear it would work.

The use case for LFS is that we have a large number of apps using static images for websites and such. In CI, we don't want to waste time cloning those files to run something like a lint script.

I'm confused what this means. The images would be fetched from your blob store at the application's runtime. For CI, you don't need to fetch them at all.

My understanding is that it is better to use repo-hosted static image files rather than an external storage

There are almost no cases where this is the preferred strategy for scaling blob assets in your system.