feat(concatjs): publish concatjs binaries on releases and fetch as a …

[alexeagle]

…toolchain

This avoids shipping three (soon to be more) copies of the binary in the @bazel/typescript and @bazel/concatjs packages. Unblocks us from publishing mac M1 binaries for example, or supporting linux on s390 or ppc

[alexeagle]

@devversion this is only partway done, still need to reference this toolchain from locations that previously used the npm-resolved path, do you have any time to work on it? I also need to do the release engineering bits to include these files in releases, which I'll do after this lands

[devversion]

@alexeagle I can definitely help with that, especially since I reported the issue initially (so it's in my own interest)

I won't have a lot of time the next week 1-2 weeks due to some large priority task for Angular v13, but might be able to already continue as a side-project. I also work on rules_webtesting m1 compat currently. This is not really urgent anyway right?

For understanding: The toolchains should fetch the artifacts from a Github release right? so basically we'll add the devserver binaries to the Github release as artifacts, or what is the plan here? If so, would that mean we always need to release first, before we can point to the "most recent" devserver changes?

[alexeagle]

there will be two paths. End-users fetch the devserver binaries from the github release, but for local dev and CI we ought to use the HEAD version, which means another little sed-style replacement in the bazel_integration_test/runner.js

Though since these change infrequently I'd be okay cutting corners and having the local dev case use a published binary as long as there's some README for testing local changes.

[alexeagle]

@devversion I included some binaries on the 4.1.0 release to bootstrap the process. I'll update the release process for the next one to make sure these are built with -c opt and have the computed SHAs inserted into the new repositories.bzl file.

I added a couple more untested files here to fetch those and create the toolchain targets. LMK when you have some time :)

[trik]

any news on this? as a temporary workaround to be able to run concatjs devserver on m1, could it be feasible to use x64 binary through rosetta2? it's just a couple of lines, i can do a pr

[alexeagle]

no news, no one has had time, sorry

[trik]

no news, no one has had time, sorry

maybe i could help? i can see from your pr that the on-release.js script has to be completed to update computed sha in repositories.bzl and linux ppc64le and s390x binaries are still missing

[alexeagle]

Sure, help would be great. There are some notes up the thread about other parts that aren't finished. It might be tricky to figure out how it's wired together though.

[trik]

i think i've completed the binaries generation and i added some lines of code to the on-release script to fill binaries sha in bazel file.. https://github.com/trik/rules_nodejs/commit/296d2eec20962af504f8aa7154041b3a8499d19a it's still not clear to me how you would deal with local dev. we have to provide a fallback local repository?

[github-actions[bot]]

This Pull Request has been automatically marked as stale because it has not had any activity for 6 months. It will be closed if no further activity occurs in 30 days. Collaborators can add a "cleanup" or "need: discussion" label to keep it open indefinitely. Thanks for your contributions to rules_nodejs!

[github-actions[bot]]

This PR was automatically closed because it went 30 days without any activity since it was labeled "Can Close?"