build: Move to single-file builds for craft

[BYK]

This PR reduces the build times dramatically (10x) by generating
a minimized single-file build of Craft binary via esbuild. Using
a single-file build makes is more portable so one can simply do
curl <CRAFT-URL> and use craft directly instead of doing an
npm install. This is especially useful for our centralized publish
repo flows and actions.

IMPORTANT: This PR sacrifices the update checker as it uses lazy imports for certain things. We can try to make it work with static builds but I'm not sure if it's a feature that's worth the effort.

[tonyo]

🏄

[chadwhitacre]

This PR sacrifices the update checker as it uses lazy imports for certain things. We can try to make it work with static builds but I'm not sure if it's a feature that's worth the effort.

@BYK You and I talked about this elsewhere, doesn't feel great to sacrifice functionality for technical reasons. If we must, we must.

[BYK]

@tonyo I took the path for adding update-notifier back and actually us using is-ci to populate the default value of the --no-input argument. Thoughts?

[BYK]

@chadwhitacre I walked back from using update-notifier as it adds unnecessary bulk and even if there is a way for the author to make it compatible with static linker, they were dismissed without much thought (yeoman/update-notifier#123 (comment), yeoman/update-notifier#159 (comment)). There is a fork but I don't think this is worth such an effort. If we find this feature, I'm quite sure we can implement a simpler version without all this pain.

[chadwhitacre]

Approving with the following caveats:

1. It's too bad we have to choose between update-notifier and esbuild. :-/
2. I don't see that we actually use the Docker image ourselves, not sure why we bother building that.
3. I'm not sure I trust that we won't hit a bug at some point because of the other warnings we're ignoring.
4. I don't really understand why we're adding dist/craft to the GitHub artifacts we're uploading, since we will be curling from elsewhere in action-prepare-release (and continuing to craft as an action via GitHub ref in prepare).

[BYK]

It's too bad we have to choose between update-notifier and esbuild. :-/

We can get similar functionality by ourselves or resort back to using update-notifier-webpack if we find it necessary. I'm not willing to depend on a package where the author is dismissive of simple requests to make the package easier to use.

I don't see that we actually use the Docker image ourselves, not sure why we bother building that.

It is being used by the Craft GitHub Action:

craft/action.yml

Lines 17 to 24 in d34cf65

	runs:
	using: 'docker'
	image: 'docker://getsentry/craft'
	args:
	- ${{ inputs.action }}
	- ${{ inputs.version }}
	- ${{ inputs.action == 'publish' && (inputs.no_merge || inputs.keep_branch) && inputs.no_merge || '--' }}
	- ${{ inputs.action == 'publish' && (inputs.no_merge || inputs.keep_branch) && inputs.keep_branch || '--' }}

This action is being used in the publish repo: https://github.com/getsentry/publish/blob/514489dfce586772287ce3bcc7a01c86f49b1ce1/.github/workflows/publish.yml#L60-L65

I'm not sure I trust that we won't hit a bug at some point because of the other warnings we're ignoring.

I'll revisit our yargs usage where most of the warnings are coming from. I made sure all dynamic require paths are covered with the changes in this patch.

I don't really understand why we're adding dist/craft to the GitHub artifacts we're uploading, since we will be curling from elsewhere in action-prepare-release (and continuing to craft as an action via GitHub ref in prepare).

These will be used when cutting a release to GitHub where we attach all the assets from the build to the release tag.

[chadwhitacre]

These will be used when cutting a release to GitHub where we attach all the assets from the build to the release tag.

... and presumably this copies the assets over so the 90-day retention period doesn't apply.

[BYK]

... and presumably this copies the assets over so the 90-day retention period doesn't apply.

Yup. As far as I'm aware release assets are stored indefinitely.

[chadwhitacre]

cutting a release to GitHub where we attach all the assets from the build to the release tag

craft/src/targets/github.ts

Line 267 in 7bf3f70

public async getAssetsForRelease(

craft/src/targets/github.ts

Line 306 in 7bf3f70

public async uploadAsset(

👍