DEV Community: Emilia

Nixing Homebrew: Streamlining package management on your machine

Emilia — Mon, 18 Sep 2023 03:08:44 +0000

As someone who deals with package management on the daily, whether it’s pnpm or cargo, I have grown tired of brew rather lacklustre proposition. If you’re happy with brew, by all means, stick with it! I’m not vibing with it anymore though.

Why I do consider brew so lacking

There are quite a few reasons for this:

It’s slow. I don’t think ruby itself is the main reason, but the rather simplistic nature of brew’s architecture plays a part.
You can only interact with the CLI. This is pretty bad, as there’s no file that declares your dependencies like a package.json or a Cargo.toml. This makes multi-machine management an exercise in frustration.
As a consequence of this, managing versions is… not exactly ideal either. Yes, things like fnm, virtualenv, and rustup are cool, but they only exist to fill a gap in most OS package managers. And that’s just programming languages, sometimes I want to avoid upgrading a binary, like postgres.
Another missing feature is the lack of lock files. yarn ’s release was a transformative moment in the javascript ecosystem. It established how important these were, at a time where npm did not provide them.
Auto upgrades can be harmful. This is due to the lack of versioning, but I’ve had breakage in my dev environment because adding a package also upgraded majors on other packages. This behaviour can be improved with HOMEBREW_NO_INSTALL_UPGRADE or HOMEBREW_NO_AUTO_UPDATE, but they introduce other problems, and they aren’t the default.
It doesn’t handle configuration management. In my dotfiles, I still have to invoke stow . And even if I use a script, stow sometimes generates its symbolic links too eagerly, bothersome when applications clutter their configuration directory. Yes, looking at you fish 😠
It’s a mess on apple silicon. Once you’re past the initial humps, it’s okay-ish. OS upgrades will still be painful, and the intel experience remains simpler.
It’s less nice than linux package managers, and I run/manage linux machines aside from my MBP, so I’d love a common tool, or something at least on par. My only BSD is a truenas server which I manage via a local web interface.

And yes, homebrew bundle exists, and fixes some of these issues. But that means it sits in an awkward space, where it fills some of the expectations, but falls short due to the parent tool not catering to that paradigm. And the fact that you can inadvertently work around it is not helping. It’s also mentioned once on brew.sh, which does not inspire confidence.

Getting an alternative

There aren’t a lot of package managers that can fill that void. Fink and MacPorts are pretty much macOS only, and linux package managers tend to be linux-only. They can run on macOS, but it’s a path full of pain, and it’s a lot of manual steps. Which is the opposite of what I’m looking for, automation is the name of the game here. The only viable solution I was able to find was nix. Nix is many things beyond a simple package manager, but I want to stay simple for now. The goal is to manage my applications, and my dotfiles. There might be something else I’m not aware of, in which case I’d love to hear about it!

Getting on with nix

Installing nix

You might be tempted to use the command that nixos.org recommends, but will be better off using another path: the Determinate Nix installer. The reasons are detailed on the Zero to Nix website. It offers a cleaner install/uninstall experience, essential when trying something out. To use it, type the following command.

curl --proto '=https' --tlsv1.2 -sSf -L https://install.determinate.systems/nix | sh -s -- install

That should bring nix to your machine, using the optimal setup for macOS, and that's it. You now have a working nix installation on your Mac. To check that things are in working order, you can type the following command:

nix search nixpkgs neovim

Now that we’re done with the installation, this is where a lot of tutorials would tell you to install nix-darwin. Don’t bother: it’s a lot of additional complexity, in an intrusive package. It allows you to tweak things at the OS level, but you pay too big a price. What’s worth it though, is home-manager. Using a flake, it’ll allow us to forget (or rather never learn) about a lot of nix commands, and get a pre-packaged shell with all the stuff you declared.

Installing home-manager

Home-manager is what is going to be handling my dotfiles. It also enabling me to let a flake manage everything rather than editing nix’s configuration. Here’s the minimal configuration I went with, separated in two files. Replace <username> with whatever yours is to get going (echo $USER will tell you what you username is if you aren’t sure):

`flake.nix`

{
  description = "Emilia's dotfiles";

  # inputs are other flakes you use within your own flake, dependencies
  # if you will
  inputs = {
    # unstable has the 'freshest' packages you will find, even the AUR
    # doesn't do as good as this, and it's all precompiled.
    nixpkgs.url = "github:nixos/nixpkgs/nixpkgs-unstable";
    home-manager = {
      url = "github:nix-community/home-manager";
      inputs.nixpkgs.follows = "nixpkgs";
    };
  };

  # In this context, outputs are mostly about getting home-manager what it
  # needs since it will be the one using the flake
  outputs = { nixpkgs, home-manager, ... }: {
    homeConfigurations = {
      "<username>" = home-manager.lib.homeManagerConfiguration {
        # darwin is the macOS kernel and aarch64 means ARM, i.e. apple silicon
        pkgs = nixpkgs.legacyPackages.aarch64-darwin;
        modules = [ ./home.nix ];
      };
    };
  };
}

`home.nix`

{ ... }: {
  # This is required information for home-manager to do its job
  home = {
    stateVersion = "23.11";
    username = "<username>";
    homeDirectory = "/Users/<username>";
    packages = [ ];
  };
  programs.home-manager.enable = true;
  # I use fish, but bash and zsh work just as well here. This will setup
  # the shell to use home-manager properly on startup, neat!
  programs.fish.enable = true;
}

Once these files exist in the directory of your choice, then you can run:

# if your directory is part of a git repo, flake will only use files that
# are properly tracked. This caught me off-guard multiple times!
git add .
# This will run home-manager after downloading it, the same way npx would
# in JS land.
nix run github:nix-community/home-manager -- switch --flake .

This will install everything necessary by reading your flake.nix, create a flake.lock to ensure reproducibility, and do all the necessary setup. Restart with a new shell to get all the necessary goodies. To make sure it all worked: home-manager should now be in your PATH, and can be invoked on the command line.

Adding your packages

Before installing a package, we need to find it. Finding it can be done one of two ways:

On the nixOS website: NixOS Search
On the command-line: nix search nixpkgs <package>

Once you’ve determined what the package is, get its name, and then we can go add stuff to our home.nix.

# We add pkgs since it's available as an argument, thanks to our inputs
{ pkgs, ... }: {
  home = {
    stateVersion = "23.11";
    username = "emiliazapata";
    homeDirectory = "/Users/emiliazapata";
    # Then we add the packages we want in the array using pkgs.<name>
    packages = [
      pkgs.git
      pkgs.neovim
    ];
  };
  # This is to ensure programs are using ~/.config rather than
  # /Users/<username/Library/whatever
  xdg.enable = true;

  programs.home-manager.enable = true;
  programs.fish.enable = true;
}

Once you’re done, you can run this command to install these packages:

home-manager switch --flake .

Adding your configuration

To manage your dotfiles, it’s going to be in the home.nix file again. There are two ways to go about it:

Leverage home-manager and the nix language to the max, by putting the entire configuration in nix files. And figure out what needs to go where with its… questionable documentation
Tell it to put specific files in specific places.

We’re gonna go with the second option, as it’s a lot less work, and doesn’t tie you to the nix ecosystem.

{ pkgs, ... }: {
  home = {
    stateVersion = "23.11";
    username = "emiliazapata";
    homeDirectory = "/Users/emiliazapata";
    packages = [
      pkgs.git
      pkgs.neovim
    ];
    # Tell it to map everything in the `config` directory in this
    # repository to the `.config` in my home directory
    file.".config" = { source = ./config; recursive = true; };
  };
  xdg.enable = true;

  programs.home-manager.enable = true;
  programs.fish.enable = true;
}

And now, don’t forget to git add all the necessary files. Home manager will also not override files it hasn’t managed, and will ignore that silently. You will need to remove the files in your .config, in order to get home-manager to manage them. Once you’ve checked everything, same command as last time:

home-manager switch --flake .

And that’s it! You now have a nix-managed dotfiles repository, with declared packages. To ensure it all went without a hitch, you can ls -a in one of the configuration directory you handled. It should show the symbolic links pointing to somewhere in /nix/store/ like so:

lrwxr-xr-x@ 1 username  staff    84B 17 Sep 11:38 init.lua@ -> /nix/store/7svm3r3xpwhgnfsp2g0wmpycai1fvxan-home-manager-files/.config/nvim/init.lua

It’s a pretty lengthy article, but I wanted to be thorough and explain the why which tends to be hand-waved away, especially in the nix ecosystem! You can find my dotfiles and the recent changes I made in my dotfiles repo if you’re wondering what it ended up looking like in my case.

One last note: The nix discord community is pretty okay, and they helped me figure a lot of that stuff out. If you feel adventurous enough to try nix out, you might want to come hang there.

Building my own router

Emilia — Wed, 26 Aug 2020 22:50:00 +0000

I don't want to use react-router on my personal projects. Mostly because of the bloat you incur for the high degree of compatibility (even the shiny version 6 still has a fair amount of cruft).

I looked at alternatives, but truth be told, no one really wants to reinvent the wheel, and for good reasons! It works, and Facebook is probably a bigger issue if we're talking ethics. But hey, it's nonetheless a fun exercise to get acquainted with what browsers can do nowadays.

It's about leaving things behind

react-router relies on their own history package, because it wants to be compatible with react native and Internet Explorer. I do not need nor want that, so there are a fairly consequential number of wins to be had just there. Though there's a gotcha: the history API can drive events in specific cases, but you'll still need some wrapping in the cases an event is not fired.

One way to do things

react-router affords you flexibility, as it's not opinionated in how you build your routes, but that means that different codebases can look very different. I often need to jump projects at work, and the lack of consistency due to that freedom is a curse I'd rather not deal with. Having a single way to do things is simpler to explain and learn, simpler to use, and simpler to maintain.

Introducing `itsy-bitsy-router`

An evergreen-browser barebones routing solution that only offers a hook-based API, and a Link component for convenience. There's a documentation website available to get started quickly, and while it's not expansive yet, it does the job quite well, and allows me to dog-food the router with just itself.

Features

I went with a very familiar API. It works, and does the job in a very simple manner. It supports url matching the way you'd expect: path/to/:match/. It's fairly simple to use, and should cater to most use-cases! If not, that's probably something that can be improved, and opening an issue could make a difference.

It's also really lightweight, at around 1kb gzipped. This is especially valuable when considering that a router is going to be part of your initial payload no matter what.

Limitations

As history.pushState() and history.replaceState() do not fire any events, we need the useNavigate() hook to handle navigation in places where Link is not desirable. history.forward() and history.back() do work and trigger rerenders as expected though.
TypeScript can't really play nice with something like useParams(), and probably never will. So we're stuck with Record<string, string> as the return type, instead of having something that relates to the current component. I don't see an easy way out of this one given we rely on string-defined properties with the /path/to/:id API pattern. There may be an alternative API, focused on Typescript to be found at some point, but one of the selling points right now is to enable a quick opt-in/opt-out.
SSR is something that probably doesn't work as-is (Maybe?), haven't really tried. But with gatsby and next already equipped with their own routing, I'm not really willing to spend time investigating this.
There's no support for React Native. That's definitely not something I need, and I want to keep things as lean as I can.

What's next

I want to get a feel for the API as it is, and maybe adjust a few things along the way, but this should be fairly final. The one thing I really want to integrate before cutting a v1 is React's Concurrent Mode, as routing is one of the rare occasions where it really shines.

I mainly did this for myself, and for fun, but I feel like this could go further than that! If you liked it, do let me know ✨

TailwindCSS is a keeper

Emilia — Mon, 17 Aug 2020 08:46:42 +0000

Let's be honest, I was a bit dubious about Tailwind at first. I was slightly put off by the idea of not writing CSS anymore, and replacing it with terse classes. But mostly because drawbacks were never really discussed, and that's usually a red flag. No technology or paradigm is perfect, there's always a downside. Tailwind is no different!

I decided to give it a fair shake after seeing it used in front of me in a convincing manner. I used it a a small prototype, where I thought the quick iteration everyone raves about would help me be done with the prototype quicker. And therein lied my first surprise.

The learning curve is minimal

This is dependent on your editor, but vim offers intellisense completion and the framework website offers a powerful and quick search for its great documentation. Both of these allow you to dive in quickly, and keep being useful in the long run.

But that's not the end of Tailwind's strengths. I have since used it on personal projects and at work to great effect.

The good

Normalised values ensure consistency

Most designs call for consistent spacing/sizing, and having pre-determined values help tremendously in keeping the experience consistent. If you were writing CSS, chances are mistakes will happen at some stage, and some spacing will slip through the cracks and not use your CSS/Sass variables.

CSS creep can't happen

CSS is really easy to add, but a lot more complex to remove, because of the degree of separation between code and styles/layout. This means that websites tend to see the size of their CSS balloon over time. Since Tailwind uses a purging mechanism to ensure you only get the minimal subset of necessary CSS, you avoid the ballooning problem. Especially since removing a class attribute from a component will not affect the rest of your app, no matter what (This is also true with BEM, but BEM is only enforced by your own vigilance, CSS-in-JS and CSS modules do avoid that issue completely though).

Long classes are a good thing, actually

It's one of the things that kept me from trying it in the first place, but there is something nice about being able to see what a component does in terms of layout and style at a glance. The naming is indeed terse, but still explicit enough to be readable! The added benefit, if using jsx-like syntax, is that you effectively consolidated HTML/CSS/JS in a single location without the usual downsides. I said location, not file, because even templated frameworks do keep CSS separated inside the file.

Flexibility is there

Don't like the default colours, or need to map them to whatever colours the designer picked, or create new colours? It's a small change in the config. Not happy with the spacing? Same deal. Need a specific CSS attribute not handled? Can be added in the config. It's a lot more flexible than it looks. But you know what? I've never had to do more than a couple tweaks, the package is fairly complete.

A lot less things to name

Let's be honest for a minute, naming things is hard. When going for your traditional BEM naming convention, you need to name a lot of things. With Tailwind? You use the classes on offer, one less thing to worry about!

But like I said earlier, it can't be all roses.

The bad

A complete paradigm shift

Since things are so different from usual CSS methodologies, it makes it hard to integrate on an existing project without forcing you to check things in two places, and keep two ways of doing things in mind, which can make the cohabitation period somewhat painful.

Setup is slightly involved

Since Tailwind has to generate the right css file from your build, it's not plug-and-play. You really don't want to use the CDN version for any production environment, it's a whopping 1M of CSS right there, so you'll need to wrangle some configuration no matter what. The documentation does a good job of presenting you with most of the cases you may encounter, but if your stack is fairly complex, this will need a fair bit of messing around. PS: You'll almost certainly want to disable the preflight when introducing it to an old codebase.

The missing bits

Tailwind doesn’t support pseudo elements, it’s honestly a bit of a bummer. But I truly don't see a way to integrate those that wouldn't feel incredibly verbose or overly terse. Especially when pretty much all of Tailwind classes are only really impacting the component itself. I guess that's what @apply is for. 🤷‍♀️ It's also not super flexible in terms of grid layouts, but I have never needed more than what's on offer when implementing a designer's vision.

All in all, this paints a fairly good picture of Tailwind, but I tend to hold my opinions fairly loosely, which has probably helped tremendously getting behind the idea of atomic CSS and the Tailwind approach. It may not be for you or your team, but it's really one of those "you need to try it to form an opinion" kind of thing. If you have the bandwidth to try it, it comes highly recommended.

Leaving VSCode

Emilia — Wed, 05 Aug 2020 21:25:20 +0000

Spoiler alert: I'm old. Old enough that uni assignments would be mostly done by ssh'ing into the mainframe computer and work there. At a time where the editor ecosystem was quite frankly... not there. Sublime didn't exist at the time, and nano felt underwhelming compared to vim, especially with our professors handing out vim tips as we'd go through stuff.

So I learnt vim, and modal editing. And never left that knowledge behind. I feel it's quite useful if you take the time to learn it, the same way your capacities grow as you learn shortcuts for your favorite editor. Vim just placed it at the forefront. Given that most editors support vi bindings, it's not knowledge that goes to waste if you leave vim behind.

Which is what I've done for a while now! First for Emacs, which has the best vi emulation layer, and would argue edges out vim in places! It was fun while it lasted, but as I moved towards a frontend-focused role, VSCode autocomplete was too appealing a deal to think about not using it. The bindings were adequate. Limited and not super nicely integrated, yes, but adequate. The completion magic really sold it despite the modal layer shortcomings.

But let's be honest for a minute. Microsoft sucks. They went to great length to change their image, but the fact remains that the company is collaborating with rather unsavoury actors, and still struggles to treat their employees decently, especially when it comes to their marginalised workers. And I'm not ok with that. It's not really my job to fix Microsoft issues, and it's probably not something that can be fixed under our current economic system. But the fact remains that I am uncomfortable using their products, and that's the thing I can do something about, especially when it's not something that would hamper my visibility nor something that my workplace uses extensively like github. VSCode fits the bill, and so we said our goodbyes.

I tried going back to Emacs, but their LSP integration is still slow unless you're willing to go on the bleeding edge, and even then, things look uncertain when it comes to protocol extensions. A lot of the really magical stuff happens in those, and these niceties are hard to forget about. I thought that vim did not handle these either, as YCM has no appetite in doing so. But I was wrong! coc.nvim is a fully featured LSP implementation that strives to offer the same capabilities as VSCode (Not just the LSP) all in the comfort of a native modal editor. Javascript and Typescript are part of the default bundle, but other LSPs are readily available too, and work quite nicely.

I gained a lot in the transition. I don't need to leave the terminal anymore, it feels a lot snappier, which I find especially important on something I use on daily. I got back to a modal model that just works, without any quirks, and a very minimal interface to leave space for what matters: the code.

I'll probably continue fluttering around over the years to be honest, unless I actually manage to write my own thing, that works the way I want it to!

PS: I use Neovim, and you probably should too. Vim is trying to diverge more and more from Neovim, but goes in a direction that looks a lot less appealing than Neovim's roadmap.