binaries: remove generated node_modules binaries and compiled .js files

[ljmf00]

Signed-off-by: Luís Ferreira [email protected]

[ljmf00]

Closing this. Javascript and this Github action integration is just bad :(

[WebFreak001]

the node_modules is required by github actions, it doesn't do an install

[ljmf00]

the node_modules is required by GitHub actions, it doesn't do an install

Yes. A better way would be to bundle only the required stuff from the dependencies in a file and have a developing branch and then deploy the generated files the actual action to the release branches (v1, v2, ...)

[mihails-strasuns]

Each PR branch is effectively a separate devel branch, so this is effectively how it works already. We have agreed to switch node_modules to a bundled version though, so it is only a matter of someone doing the implementation (would be cool to do it automatically on a PR merge).

[ljmf00]

Each PR branch is effectively a separate devel branch, so this is effectively how it works already. We have agreed to switch node_modules to a bundled version though, so it is only a matter of someone doing the implementation (would be cool to do it automatically on a PR merge).

What I was trying to say is having a development branch in the upstream instead of pushing directly to version branches or changing tags, this is generally a bad practice because changing a version, for whatever reasons is bad. When a user relies on a version, that version shouldn't change, and therefore, the upstream branch related to that version shouldn't change too.

[mihails-strasuns]

But a version is a tag. If you depend on untagged version branch in your yml, you are explicitly opting in for the latest version of that branch. I could understand the concern if there was any additional stabilization stage needed, but for setup-dlang anything that is good enough to pass CI in PR, is good enough to be immediately released (and there is no extra verification involved).

[PetarKirov]

@ljmf00 btw I fixed this issue in #43

[ljmf00]

@ljmf00 btw I fixed this issue in #43

Thanks 👍

[ljmf00]

But a version is a tag. If you depend on untagged version branch in your yml, you are explicitly opting in for the latest version of that branch. I could understand the concern if there was any additional stabilization stage needed, but for setup-dlang anything that is good enough to pass CI in PR, is good enough to be immediately released (and there is no extra verification involved).

Oh, ok screw that part then. I completely missed the fact that this repo is being tagged.