1

I am building a plugin for my website that should do some antispam (primarily educational reasons). It has mostly been finished but now I am now hitting a massive speedbump in the final bits before I want to start doing "live" trials with it.

You see, I have published the plugin onto Packagist but the problem is that Packagist only takes what is in the repo but doesn't take the assets that I roll out of my pipelines in the form of artifacts (which is the final JS that the client can understand and use).
Without this, however, the plugin cannot work.
But in my experiences, compiling the code on my local machine and then manually committing it to Git is a huge pain and caused a lot of errors in the past (because sometimes I would forget to commit the JS, sometimes I would forget to commit the TS, or I would forget to recompile it all etc. etc.). In this case, Typescript, however, is somewhat interchangeable with things like SCSS (basically any front-end asset that still has to be compiled somewhere).

So my question is how I would go about this, because obviously, I don't want to just go and tell people that want to use this plugin (I try to build code assuming they are): "yea, you can use it but you are going to need to setup a typescript compiler and everything regardless if you are going to make changes to the plugin".

Finlay Roelofs
  • 533
  • 6
  • 21
  • 1
    *"because sometimes I would forget"* -> automation. Either have a script you can run locally and run in with a git hook, or automate it in CI somewhere. – jonrsharpe Apr 14 '20 at 16:27
  • I have looked into doing it with a git hook but that would incur some additional issues as well because I might use tool A for it while others use tool B or even tool C (which might not be the same command). Automating it in CI is what I currently do but this has the issue of Packagist not being able to use the artifacts from it. – Finlay Roelofs Apr 14 '20 at 16:52
  • What "others"? Why are other developers of your plugin using different build tooling? And you say that Packagist just takes what's in the repo, is the CI not publishing artifacts back to the repo? I'd suggest having *two* branches, one you work on and one that's just for Packagist to use. – jonrsharpe Apr 14 '20 at 16:55
  • Quite literally anyone interested in doing so. They can be using different build tooling for a variety of reasons (I can't come up with one directly but past experiences have shown me, people always find a way). And no, the CI is not publishing the artifacts back to the repo (well... not into the repo's actual code that is, just something on the side). So having the extra branch wouldn't help there either because there is nothing different between the "working" branch and the "Packagist" branch. – Finlay Roelofs Apr 14 '20 at 17:06
  • Whether you go that way or not, it's reasonable to require or suggest that contributors to follow your tooling conventions; document them in the repo. And I thought you were describing a situation where there *is* something different: the compiled assets. Please [edit] the question to clarify your context and why the obvious answers don't apply. – jonrsharpe Apr 14 '20 at 17:08
  • No, the compiled assets only exist in the pipeline (and as pipeline artifacts) currently. I'l update as to clarify. – Finlay Roelofs Apr 14 '20 at 17:09
  • 1
    And *that's the problem*, no? If there was a branch that *did* include them, Packagist could use that. – jonrsharpe Apr 14 '20 at 17:10
  • Exactly! (I'm sorry if the initial explanations were confusing you, I did my best to explain it all) – Finlay Roelofs Apr 14 '20 at 17:16
  • So why don't you do that, have the CI build push the code *with the assets* (and without anything that's just for dev) to a deployment branch that packagist then uses? – jonrsharpe Apr 14 '20 at 17:17
  • Well... honestly... because I didn't really think about that... I'll try to get that working! – Finlay Roelofs Apr 14 '20 at 17:20
  • So I've tried having the CI push the code with the assets but it doesn't do so because the files are obviously in a .gitignore... but then comes the thing... if I were to force push them, they'd just become tracked and potentially a few hundred output files (it currently are only 4 but this could potentially become more, I always am keeping these cases in mind) would pop-up into my Git client... which is extremely messy... – Finlay Roelofs Apr 14 '20 at 17:56
  • Why assume that the deployment and development branches would have the same ignore file? They contain *different things*. – jonrsharpe Apr 14 '20 at 18:15
  • So what you say is that when I push to the deployment branch (which currently is non-existent though, it just pushes it to the branch that the commit runs from, because else it becomes a massive mess for use with packagist I realized) I should ditch the gitignore? – Finlay Roelofs Apr 14 '20 at 18:19
  • 1
    Or switch to a different one, as you'll probably still want to ignore stuff. And you need to have two branches or you'll get a different mess. Check out my blog repo, for example, that uses the master branch for GitHub Pages deployment and the source branch for the source code: https://github.com/textbook/textbook.github.io. But I don't have further time, you'll have to figure things out from here. I'd suggest deleting this then asking again if you have a more specific question. – jonrsharpe Apr 14 '20 at 18:25
  • Thanks, I'll have a look at what you've done. I appreciate the time you offered me to help me out :) – Finlay Roelofs Apr 14 '20 at 18:29

0 Answers0