Glistix v0.7.0 (2025-03-15)

Base Gleam version: v1.7.0
Updated Glistix to Gleam v1.7.0 (#39).
- Most notably, this brings support for Nix FFI files in subdirectories! This is a very important step for Glistix, as it allows, for example, gradual adoption of Gleam in an existing Nix config or codebase by interfacing with existing files.
- Other goodies include custom pattern matching errors, record variant deprecation, generate decoder code action (soon to be fully supported by Glistix when glistix_stdlib is updated), extract variable code action, and more.
- See the Gleam blog post for the full news: https://gleam.run/news/improved-performance-and-publishing/
Dependency patching for Nix support has received great improvements! (#44 and #48)
- Read "Migration instructions" below to upgrade existing Glistix projects.
- There is a new gleam.toml section for Glistix projects: [glistix.preview.patch].
- This section has a similar syntax to the dependencies section, and is used to replace transitive dependencies with other packages, even if they have different names, such as forks adding Nix target compatibility.
- For example, one can replace gleam_stdlib with glistix_stdlib (now published on Hex) using the snippet below:
```
[glistix.preview.patch]
gleam_stdlib = { name = "glistix_stdlib", version = ">= 0.34.0, < 2.0.0" }
```
- With that snippet, all packages in your dependencies which depend on gleam_stdlib will depend on glistix_stdlib instead, thus gaining Nix target support (where possible).
- Please note that this setting only has an effect on top-level projects. Patches from dependencies are ignored, though they may have their own patches to be able to run unit tests, for example (so it's still useful for packages).
- This setting effectively deprecates the existing local-override and hex-patch options. local-override can be achieved through patch by patching an incompatible local package to the same local package your project is using, whereas hex-patch can be achieved by specifying the dependencies you want published to Hex in [dependencies] and the dependencies you want to use when running your project in [glistix.preview.patch]. After some time, it's likely those settings will be removed.
Glistix now uses a "patchset" model for fork maintenance, which should hopefully lead to faster and cleaner Gleam version bumps. (#42 and #43)
- This works by keeping a branch with all changes applied to the upstream Gleam codebase. A Gleam version bump then consists of rebasing those patches on top of the updated codebase, letting us know which patches are outdated and which patches need fixing, rather than relying solely on the maintainer's recollection of events.
Backported an upstream fix for publishing packages with native (.nix) files in subdirectories. (#46)
- This ensures you can publish packages to Hex using the new feature of .nix files in subdirectories introduced in this update.
Some JS target fixes from Gleam v1.7.0 were ported to the Nix target as well. (#40)
- If you have a file named file.gleam and another named file.nix, you will now receive an error as that is invalid.
- Fixes a bug where string pattern matching nested in patterns would generate wrong Nix code.

Migration instructions

There are new instructions for patching Gleam packages with Nix-compatible forks, as noted in "Overriding incompatible packages".
If you were using the default Glistix project configuration, you're likely depending on the standard library through a local dependency on a Git submodule.

In that case, you should remove the stdlib submodule and start using a patch to glistix_stdlib which is available on Hex using the instructions below.
1. Run git rm external/stdlib to remove the external/stdlib submodule.
2. Replace the local gleam_stdlib dependency with either a direct dependency on glistix_stdlib, or with a dependency on the original gleam_stdlib together with a patch. (A patch is necessary regardless of your choice, since your dependencies themselves will still be depending on gleam_stdlib.)
  
  Tip: You can check out the new default gleam.toml file for Glistix projects in "Project configuration" and copy its contents over to your project, allowing you to quickly apply the necessary changes to your configuration.
```
  [dependencies]
- gleam_stdlib = { path = "./external/stdlib" }
+ gleam_stdlib = ">= 0.34.0 and < 2.0.0"
+ # OR (for packages only available for the Nix target):
+ # glistix_stdlib = ">= 0.34.0 and < 2.0.0"
+
+ [glistix.preview.patch]
+ # Replaces 'gleam_stdlib' with 'glistix_stdlib' on all transitive dependencies.
+ # This is needed so stdlib will work on the Nix target.
+ gleam_stdlib = { name = "glistix_stdlib", version = ">= 0.34.0 and < 2.0.0" }
```
3. Delete the local-overrides and [glistix.preview.hex-patch] settings.
```
- [glistix.preview]
- local-overrides = ["gleam_stdlib"]
-
- [glistix.preview.hex-patch]
- gleam_stdlib = ">= 0.34.0 and < 2.0.0"
```
Repeat the procedure above for other forks, such as glistix_json or glistix_birl.

If you were actually using local-overrides to bypass a conflict between a local dependency in your root project and in a dependency, you can replace this with a patch.

[dependencies]
local-dep = { path = "external/local-dep" }

- [glistix.preview]
- local-overrides = ["local-dep"]
+ [glistix.preview.patch]
+ # Force transitive dependencies on local-dep to use the same path
+ local-dep = { path = "external/local-dep" }

If you were using hex-patch to be able to use local dependencies and switch to a Hex dependency when publishing your package, you can move your local dependencies to [glistix.preview.patch] and your Hex dependencies to [dependencies].

- [dependencies]
- dep = { path = "external/dep-fork" }
-
- [glistix.preview.hex-patch]
- dep = "1.2.3"
+ [dependencies]
+ dep = "1.2.3"
+
+ [glistix.preview.patch]
+ # Use local dependency when testing package locally
+ dep = { path = "external/dep-fork" }

The Glistix Handbook

Glistix v0.7.0 (2025-03-15)

Migration instructions