SemanticReleaseHex - Fully automated version management and release processes

[Eiji]

@sheerlox

The _build directory seemed the most obvious place to put binaries given the citation below, and it’s also where tailwind stores its executable.

Oh, right. Yeah, that part completely makes sense. I completely forgot about binaries. Look that hex packages and their documentation are saved globally in $HOME/.hex directory, so it could be a bit confusing for me.

@sheerlox

That being said it could be made configurable, which would for example enable sharing the same Node.js binaries between projects.

(…)

The decision for Phoenix to store node_modules in the assets directory makes sense, as it actually contains assets used during the front-end bundling process.

Then I would say follow phoenix way i.e. generate package.json as described already, but also install binaries into _build directory.

@sheerlox

Regarding semantic_release, I believe the decision to hide its node_modules behind _build makes sense, because it should only be used by itself.

Moreover, if multiple projects using nodelix install specific package versions in a shared node_modules in the root directory, that would lead to potential conflicts and unexpected behavior (without relying on a shared root package.json, which I discuss below).

Hmm … Now I see the point. Still prefer assets way, but maybe with some changes … assets/semantic_release?

@sheerlox

Currently, the idea behind semantic_release is to abstract as much as possible the fact it’s using Node.js under the hood (thanks to nodelix). Having to maintain a package.json or run npm install in an Elixir project might be seen as an unwelcome overhead for many project maintainers.

Originally I was thinking (assuming same node_modules) that developers are familiar with basic npm stuff, because as said above it’s not really something new to add Node dependencies into Phoenix projects. That’s said it may not be best for new projects … If we would follow similar things then I would look for phoenix generators which instructs developers to add routing. Here instead of routes there could be adding or modifying existing alias i.e. assets.setup. It’'s just a copy-paste and assets.setup is part of most Phoenix projects. I guess every Elixir developer which does not started learning recently would get it easily.

@sheerlox

Additionally, I believe letting the end user manage the versions himself in a root package.json would limit the library’s ability to handle compatibility with the various Semantic Release major versions.

Is that so? Not remember now how tailwind is doing that, but by default it fetches latest stable build, right? Modifying json files today is a piece of cake, so in worst case there should not be a problem with updating package.json file or maybe I have missed something again.

Also you worry about best case (actively maintained package). What about worst case (no support)? How would developers deal with possible updates? Look what have changed over years … Previously every Phoenix project was based on Webpack and now we have a completely new way i.e. esbuild.

---

Summary:

0. _build sounds really well for binaries especially if phoenix does the same thing (previously I was focused more on assets stuff)
1. Does something like assets/semantic_release, semantic_release or similar makes any sense?
2. package.json (regardless if creating in extra directory or shared with root project) is more intuitive for developers. Especially those who are new in Elixir. It’s simpler to understand well documented mix aliases than a source code of mix task in one of possibly many project dependencies.

Well … all above is not some kind of advice, but just some loose thoughts, so no need to consider everything. After what you wrote I’m no longer convinced with both node_modules in _build, in assets (shared with root project) as same as separate directory. My intuition tells me it’s something similar, but I have no idea what it might be exactly.

Right before posting I got a weird idea … apps/my_app_semantic_release/assets/node_modules or something like that, but it looks like I’m overthinking it a bit.