Generate Dist files automatically when there are changes

[yeikel]

Updating the dist manually is a hassle. I'd be nice if we had some sort of automation to update the pull request Dist when there are new changes

[jeffwidman]

We actually do have this automation in place... but I think dist only needs to be rebuilt when a prod npm dep changes?

I'm not super familiar with npm ecosystem, but based on this comment your logic change PR's shouldn't need to rebuild dist:

fetch-metadata/.github/workflows/dependabot-build.yml

Lines 34 to 35 in 173b40e

	# We only need to build the dist/ folder if the PR relates a production NPM dependency, otherwise we don't expect changes.
	if: needs.fetch-dependabot-metadata.outputs.package-ecosystem == 'npm_and_yarn' && needs.fetch-dependabot-metadata.outputs.dependency-type == 'direct:production'

If I'm wrong let me know, otherwise please close if you agree.

[yeikel]

I don't think so, because dist is the result of running npm run build and that is the result of running ncc build src/main.ts which will compile the project to a single file index.js

We also have this other workflow to validate the same : https://github.com/dependabot/fetch-metadata/blob/main/.github/workflows/check-dist.yml

But I might be overlooking something. I'll retest that and get back to you

[yeikel]

I reverted my changes to dist 808bc0f just to test, and that shows what I suspected: The dist file reflects the changes to the main code and if we don't regenerate it users won't see the features

[yeikel]

@jeffwidman One more annoyance is that small differences in the build lead to different dist files (understandable as the compiler changes)

It also seems that there are small differences across platforms as well

See this failure as an example https://github.com/dependabot/fetch-metadata/actions/runs/4652910733/jobs/8251802610?pr=336

[brrygrdn]

👋🏻 @yeikel, as I recall, we set up the automation to build the dist/ changes for Dependabot PRs just so they were easy to merge and since they were opened by a 'trusted' contributor.

The intent behind this was to avoid running ncc build for contributed code just in case there was potential for an insecure code execution exploit that could exfiltrate secrets, etc. We could have the best of both worlds by requiring the dist/ build to be successful but only running it once a PR has approval from a maintainer?

[jeffwidman]

Ah, so the code comment is incorrect then... dist/ is expected to have changes even when deps don't change...

[yeikel]

👋🏻 @yeikel, as I recall, we set up the automation to build the dist/ changes for Dependabot PRs just so they were easy to merge and since they were opened by a 'trusted' contributor.

The intent behind this was to avoid running ncc build for contributed code just in case there was potential for an insecure code execution exploit that could exfiltrate secrets, etc. We could have the best of both worlds by requiring the dist/ build to be successful but only running it once a PR has approval from a maintainer?

I think that's fair. The concern is valid as dist files are minimized and difficult to read and it would be easy for a malicious user to inject malicious code there.

Provided an automated way would secure it as well as removing that burden from the user

Ah, so the code comment is incorrect then... dist/ is expected to have changes even when deps don't change...

Yep, any source code change should re-generate the dist as the code in dist is what is ultimately executed when the action runs