Use dart2native with releases

I see here that Sass has a task for native executable:

dart-sass/tool/grind/standalone.dart

Lines 28 to 37 in ca63b1b

	@Task('Build a native-code Dart executable.')
	void nativeExecutable() {
	ensureBuild();
	run(p.join(sdkDir.path, 'bin/dart2native'), arguments: [
	'--output-kind=aot',
	'bin/sass.dart',
	'-Dversion=$version',
	'--output=build/sass.dart.native'
	]);
	}

but it appears it is not being used in the releases?

dart-sass.bat
sass.bat
src\dart.exe
src\sass.dart.snapshot

[nex3]

The filenames in the executable archives don't necessarily correspond to the filenames in the Dart SDK or the build directory; we always write src/dart(.exe) and src/sass.dart.snapshot, regardless of whether we use a script snapshot plus the full dart executable or a native snapshot plus dartaotrunner.

That said, due to a combination of https://travis-ci.community/t/windows-instances-hanging-before-install/250/8 (Windows VMs that include secure environment variables hanging on Travis) and dart-lang/sdk#28617, we're unable to compile native executables for Windows specifically in our deploy process. I recommend liking the Travis issue and 👍ing the Dart SDK issue to communicate to those teams that this is affecting you.

Well, there's nothing stopping anyone from doing this outside of a Travis environment. My understanding is Appveyor is more Windows friendly. And of course a CI is not a requirement to build something.

But I can understand if you don't want to do any of that. Cheers.

[nex3]

We make frequent releases, and automating them is a hard requirement to avoid taking up way too much developer time. There's no clean way to integrate Appveyor into our existing Travis pipeline so that, for example, it only runs after Travis has created a GitHub release to which files could be uploaded.

@nex3 another option could be, for Minor releases, like 1.23.0, 1.24.0, Make a
Windows dart2native "by hand" or however. Hopefully this wouldnt happen too
often. Then for smaller releases, like 1.24.3, 1.24.4, do the CI snapshot
thing.

Personally I would rather have an older build thats a single file, than a newer
build thats 4 files.

This would add some overhead, so again I understand if you dont want to deal
with it. But I think its a good compromise.