DEV Community: Shri

Publishing from hugo to dev.to

Shri — Tue, 23 Sep 2025 08:30:54 +0000

I have been pondering federating parts of my blog to dev.to for a bit more visibility.

However, I had a couple of issues:

With html (instead of markdown), it would not pick up the code blocks correctly
With markdown, it would render the relative links incorrectly

What I really wanted was a way to render the hugo markdown into Jekyll style (which is what forem wants) but with the links rendered.

This was a little more complicated than I would have liked.

Goals

At a minimum, I wanted two main things:

Render code blocks correctly
Relative URLs should be rendered as absolute (because they won’t work on dev.to)

Pre-existing Solutions

I found hugodevto which looked promising except:

Not a fan of having to manually update hundreds of posts with the devto id
Had a couple of fiddly bits to get it working (my plain text outputs had some troubles for unknown reasons)
It rendered image urls, but not regular urls.

Ultimately though, it felt a bit bulkier than what I was looking for

Using Hugo

I had done enough work with hugo and output formats to have a vague idea of how to make it work.

Limitations

There are a few limitations to doing it this way though. Hugo does not provide render hooks for everything . You will end up with html in the output. However, since Forem (and Jekyll) will just render them, it fits my use case. It won’t work as well if you try and use this to generate like for like markdown usable in Jekyll.

Define a new content type

We want a new content type which will output markdown

```toml [outputFormats.jekyll] mediaType = "text/markdown" baseName = "index" isPlainText = true isHTML = false notAlternative = true path = 'jekyll' # put the output in `public/jekyll` so it's easier to find [outputs] page = ['html', 'jekyll'] # Output all pages in our jekyll format as well ```

You also need a basic template before hugo will output our markdown files.

layouts/_default/single.jekyll.md

---
title: {{ .Title }}
published: true
date: {{ .Date }}
{{- with .Params.tags }}
tags: [{{ delimit . ", " }}]
{{- end }}
canonical_url: {{ .Permalink }}
---

{{ .Content }}

With this, if you hugo build, it’ll render the .md files, but the content will be html.

Render code blocks as markdown

We can use the code block render hook to “convert them” back to markdown.

layouts/_default/_markup/render-codeblock.jekyll.md

Render absolute urls

I already have a pretty extensive render-link so updating it was just a case of making a copy of it and replacing relative url references with absolute ones.

It’s fine for it to be in html because Forem will still render it correctly. They could be rendered as markdown and it should work just as well.

layouts/_default/_markup/render-link.jekyll.md

{{ /* other content */ }}
  <a href="{{ printf "%s#%s" .PageInner.Permalink $u.Fragment | safeURL }}" {{ with .Title }}title="{{ . }}"{{ end }}>{{ $text }}</a>
{{ /* other content */ }}

Output

With these relatively minor changes, I was able to render markdown files I could then pop into dev.to and it works for the handful I set up.

Next Steps

Images

One big glaring omission is images - it’s not as relevant for me because I rarely use images.

I expect it to be easy enough to use the image render hook to achieve this.

Automation

Once the above two are done, it would be good to automate it. I could

get all the posts
get all the local posts
map them based on the canonical url (which is returned by the endpoint)
upload updated ones.

Not all my posts are technical, so I’d also want to add a field to the frontmatter (devto_published) and figure out a way to push updates only if there are changes.

Conclusion

I have a working solution for now - and if dev.to brings enough traffic / value, then I’ll consider spending a bit more time adding polish.

For the time being though, seems to work!

Feel free to use any of this code (such that it is) as you wish.

Using `locateFile` to have js and wasm in different locations with emscripten

Shri — Thu, 18 Sep 2025 09:15:42 +0000

Originally published at drone-ah.com

As part of building shine, I am using
lume and webassembly with zig.

zig, through emscripten generates both a js and wasm file, which, by default are
expected to be in the same directory.

I wanted to put them in different places, and struggled to get that working with
lume for a bit. I did eventually solve it though:

Include emscripten js file

Firstly, the js file output from emscripten should be included in you page
manually. I had used site.add which meant that it was loaded before we could
put the override for locateFile in window.Module.

I am using the
simple-blog theme, so I add the
following line to the top of src/index.vto

<script defer src="/js/shine.js"></script>

Override `Module`

You can override how emscripten finds the wasm file in the
Module Object.

This can be done in the html file in a script block, or even better, in a js
file that is included automatically.

js/main.js felt like a good place.

window.Module = {
  locateFile: function (path, scriptDirectory) {
    if (path === "shine.wasm") {
      return "/static/shine/shine.wasm";
    } else {
      return scriptDirectory + path;
    }
  },
};

Closing

With this setup, I can not only have the js and wasm files in different
locations, it's also easy to modify / augment the Module object.

Calling Javascript from Zig through WebAssembly

Shri — Wed, 17 Sep 2025 14:52:20 +0000

The next step for shine is to build a bridge between zig and javascript .

I am currently planning to using supabase for storage. Unsurprisingly, it does not have a zig sdk. It does, however, have a javascript sdk.

If I can write basic CRUD operations in javascript and call that from zig through webassembly, that could make that integration a lot easier.

Goals

There are a few ideal restrictions for me - mainly because writing javascript is not fun for me.

Use the Supabase js/ts library through zig
Use TypeScript as much as possible. (I don’t love TypeScript, but at least it’s not javascript)
Keep as much of the supabase related code in the web part so that deno and lume can handle any heavy lifting.

Options

I can’t use FFI(Foreign Function Interface):

extern "env" fn jsLog(ptr: [*]const u8, len: usize) void;

extern "env" fn jsLog(ptr: [*]const u8, len: usize) void;

const wasm = await WebAssembly.instantiateStreaming(fetch("prog.wasm"), {
env: {
jsLog: (ptr, len) => {
/* read from memory and console.log */
},
},
});

because imgui pulls in emscripten, which means we don’t have the ability to call instantiateStreaming.

With emscripten, declaring an external function is easy enough.

extern fn jsLog(ptr: [*]const u8, len: usize) void;

There are a couple of options to wire them up to the javascript:

`library.js` / `mergeInto`

This option requires javascript files on the zig side. If you want to start with typescript, you’ll need to integrate a transpiler into the build chain as well.

First, you want a javascript file - let’s call it libshine.js, and pop it into a js dir.

// js/libshine.js
// Emscripten will provide these globals at link/runtime
declare var mergeInto: (lib: any, funcs: Record<string, Function>) => void;
declare var LibraryManager: { library: any };
declare function UTF8ToString(ptr: number, len?: number): string;
mergeInto(LibraryManager.library, {
jsLog: (ptr: number) => {
const msg = UTF8ToString(ptr);
console.log("🟢 Zig says:", msg);
},
});

We then need to pass this js file into the build step

as part of my sokol build step, I pass it in as .extra_args.

// create a build step which invokes the Emscripten linker
const link_step = try sokol.emLinkStep(b, .{
.lib_main = shine,
.target = opts.mod_main.resolved_target.?,
.optimize = opts.mod_main.optimize.?,
.emsdk = dep_emsdk,
.use_webgl2 = true,
.use_emmalloc = true,
.use_filesystem = false,
.shell_file_path = opts.dep_sokol.path("src/sokol/web/shell.html"),
// set the js file here
.extra_args = &.{
"--js-library", "js/libshine.js",
},
});

We can then call it from zig, with something like:

pub fn main() void {
jsLog("hello from zig");
}
extern fn jsLog(ptr: [*]const u8) void;

From my firefox console:

Lume live reloading is ready. Listening for changes...     localhost:3000:102:15
🟢 Zig says: hello from zig                                shine.js:3168:11

`EM_JS` / `EM_ASM`

The other option is to use EM_JS which involves writing a wee bit of C, which can embed the javascript.

In theory, it’s as simple as:

#include 
<emscripten.h>
EM_JS_DEPS(bla, "$UTF8ToString");
EM_JS(void, jsLog, (const char* s), {
console.log(UTF8ToString(s));
});

and adding it into the build file:

// build the main file into a library, this is because the WASM 'exe'
// needs to be linked in a separate build step with the Emscripten linker
const shine = b.addLibrary(.{
.name = "shine",
.root_module = opts.mod_main,
});
// get the Emscripten SDK dependency from the sokol dependency
const dep_emsdk = opts.dep_sokol.builder.dependency("emsdk", .{});
// need to inject the Emscripten system header include path into
// the cimgui C library otherwise the C/C++ code won't find
// C stdlib headers
const emsdk_incl_path = dep_emsdk.path("upstream/emscripten/cache/sysroot/include");
shine.root_module.addCSourceFile(.{
.file = b.path("src/libjs.c"),
.flags = &.{}, // optional extra emcc flags
});
shine.addSystemIncludePath(emsdk_incl_path);

The calling code in main.zig remains the same:

pub fn main() void {
jsLog("hello from zig");
}
extern fn jsLog(ptr: [*]const u8) void;

However, this didn’t work, and failed with:

error: undefined symbol: jsLog (referenced by root reference (e.g. compiled C/C++ code))
warning: To disable errors for undefined symbols use `-sERROR_ON_UNDEFINED_SYMBOLS=0`
warning: _jsLog may need to be added to EXPORTED_FUNCTIONS if it arrives from a system library
Error: Aborting compilation due to previous errors

Thanks to some help from flooh (who btw put together the sokol and sokol-zig packages as well the sokol-imgui-sample template which I used to kick start this project.), I was able to get it working.

Turns out the c file needs to have a function in it that is used in the zig file - it doesn’t need to do anything.

So, based on the suggestion, libjs.c changes to:

#include 
<emscripten.h>
EM_JS_DEPS(bla, "$UTF8ToString");
EM_JS(void, jsLog, (const char* s), {
console.log(UTF8ToString(s));
});
void dummy(void) {};

and in main.zig:

pub fn main() void {
dummy();
jsLog("hello from zig");
}
extern fn jsLog(ptr: [*]const u8) void;
extern fn dummy() void;

From my firefox console:

Lume live reloading is ready. Listening for changes...     localhost:3000:102:15
🟢 Zig says: hello from zig                                shine.js:3168:11

You can see a working example in [my forked repo](

`EM_JS` directly through `zig` [unsuccessful]

Looking at the macro for EM_JS and with my good friend ChatGPT, I attempted translating it to zig and made some progress, but ultimately failed to get it working. I’ll leave the work here in the hopes it might be helpful.

#define _EM_JS(ret, c_name, js_name, params, code)                             \
_EM_BEGIN_CDECL                                                              \
ret c_name params EM_IMPORT(js_name);                                        \
__attribute__((visibility("hidden")))                                        \
void* __em_js_ref_##c_name = (void*)&c_name;                                 \
EMSCRIPTEN_KEEPALIVE                                                         \
__attribute__((section("em_js"), aligned(1))) char __em_js__##js_name[] =    \
#params "
<::>
" code;                                                       \
_EM_END_CDECL

The above macro translates to zig roughly (with help from ChatGPT) as:

extern fn jsLog(ptr: [*]const u8) void;
/// 2. Keep a reference to avoid the linker removing the function.
///    Same role as __em_js_ref_* in the C macro.
pub export const __em_js_ref_jsLog = &jsLog;
/// 3. Embed the JS implementation in a special section called "em_js".
///    Emscripten will scan this and inject the code into the output JS.
export const __em_js__jsLog align(1) linksection("em_js") =
"(const char* s)
<::>
{ console.log(UTF8ToString(s)); }\x00";
pub export fn dummy() void {}

I added a pub fn and called it from main:

pub fn log(ptr: [*]const u8) void {
jsLog(ptr);
}

Which gave me the familiar error about not being able to find jsLog.

comparing the linker sections gave some clues:

❯ wasm-objdump --section=linking -x <path/to/libjs.o>
libjs.o:        file format wasm 0x1
Section Details:
Custom:
- name: "linking"
- symbol table [count=9]
- 0: F 
<dummy>
func=1 [ binding=global vis=hidden ]
- 1: D 
<__em_js_ref_jsLog>
segment=0 offset=0 size=4 [ binding=global vis=hidden ]
- 2: F 
<jsLog>
func=0 [ undefined explicit_name binding=global vis=default ]
- 3: D 
<__em_js__jsLog>
segment=1 offset=0 size=53 [ exported no_strip binding=global vis=hidden ]
- 4: S <.debug_abbrev> section=7 [ binding=local vis=default ]
- 5: G 
<env.__stack_pointer>
global=0 [ undefined binding=global vis=default ]
- 6: S <.debug_str> section=9 [ binding=local vis=default ]
- 7: T 
<env.__indirect_function_table>
table=0 [ undefined exported no_strip binding=global vis=default ]
- 8: S <.debug_line> section=10 [ binding=local vis=default ]
- segment info [count=2]
- 0: .data.__em_js_ref_jsLog p2align=2 [ ]
- 1: em_js p2align=0 [ RETAIN ]

and the zig object:

❯ wasm-objdump --section=linking -x js.o
js.o:   file format wasm 0x1
Section Details:
Custom:
- name: "linking"
- symbol table [count=6]
- 0: F 
<dummy>
func=1 [ binding=global vis=default ]
- 1: D 
<__em_js_ref_jsLog>
segment=0 offset=0 size=4 [ binding=global vis=default ]
- 2: F 
<jsLog>
func=0 [ undefined explicit_name binding=global vis=default ]
- 3: D 
<__em_js__jsLog>
segment=1 offset=0 size=4 [ binding=global vis=default ]
- 4: D 
<__anon_946>
segment=2 offset=0 size=54 [ binding=local vis=default ]
- 5: T 
<env.__indirect_function_table>
table=0 [ undefined exported no_strip binding=global vis=default ]
- segment info [count=3]
- 0: .rodata.__em_js_ref_jsLog p2align=2 [ ]
- 1: em_js p2align=0 [ ]
- 2: .rodata.__anon_946 p2align=0 [ ]`

From what I could understand (which is little), it looks like __em_js__jsLog in the zig obj is a pointer while from C, it’s the full string.

hardcoding it as a static array helped:

export const __em_js__jsLog align(1) linksection("em_js") = [_]u8{
'(', 'c','o','n','s','t',' ','c','h','a','r','*',' ','s',')',
'<',':',':','>','{',' ',
'c','o','n','s','o','l','e','.','l','o','g','(',
'U','T','F','8','T','o','S','t','r','i','n','g','(',
's',')',')',';',' ','}','\x00',
};

The output from this is a little more promising

❯ wasm-objdump --section=linking -x js.o
js.o:   file format wasm 0x1
Section Details:
Custom:
- name: "linking"
- symbol table [count=5]
- 0: F 
<dummy>
func=1 [ binding=global vis=default ]
- 1: D 
<__em_js_ref_jsLog>
segment=0 offset=0 size=4 [ binding=global vis=default ]
- 2: F 
<jsLog>
func=0 [ undefined explicit_name binding=global vis=default ]
- 3: D 
<__em_js__jsLog>
segment=1 offset=0 size=53 [ binding=global vis=default ]
- 4: T 
<env.__indirect_function_table>
table=0 [ undefined exported no_strip binding=global vis=default ]
- segment info [count=2]
- 0: .rodata.__em_js_ref_jsLog p2align=2 [ ]
- 1: em_js p2align=0 [ ]

Let’s look at the two side by side

# From C
- 3: D 
<__em_js__jsLog>
segment=1 offset=0 size=53 [ exported no_strip binding=global vis=hidden ]
# From zig
- 3: D 
<__em_js__jsLog>
segment=1 offset=0 size=53 [ binding=global vis=default ]

There are some clear differences in how the two are output and I am already beyond my knowledge level here - so I’ll leave it to someone who knows this stuff better (or wait until I do)

You can check out the code in the branch of my forked repo

Next steps

My plan is to use EM_JS through C to implement glue JavaScript functions - something like:

EM_JS(void, jsLog, (const char* s), {
Module.jsLog(UTF8ToString(s));
});

By doing this, I can have one-line js code in the .c file and all the implementation can go into the web side (and can easily be TypeScript too).

window.Module = {
jsLog: function (msg) {
console.log("🟢 Zig says:", msg);
},
};

Auto reload WASM with zig+lume

Shri — Wed, 17 Sep 2025 11:20:51 +0000

I’ve been taking some time off to rest and recover from health issues that made
it hard to focus. To ease back in, I’ve started a small project:
shine

The project would do well to be multiplatform - mobile and web. The obvious
choice was flutter and I have enjoyed working with it before.

However, as I'm currently in love with zig, I wanted to work with
that instead.

Libraries

Graphics

I've been playing with raylib and that was my initial instinct.
However, raylib
does not support iOs and
has issues with wasm

I considered a few options, including

sdl, which looked great but was perhaps a little too low level for me.
jok - does not support mobile and possibly has a little more than I needed.

In the end, I decided to go with sokol and
sokol-zig.

While a little more lower level than raylib, it has:

a modern clean api
first class mobile support
first class wasm support

UI

I've been working with dvui a lot recently. Unfortunately, it
doesn't support sokol. imgui is a better
option.

There is even a
template project that I could start from.

WASM first

To keep things straightforward, I decided to start with wasm. If I make the site
mobile friendly, I could see how it goes and see if it needs a mobile version.

I will need some shared data storage and have been considering
supabase, which has javascript
libs. By using wasm, I can effectively shim in js functions to
handle that instead of having to write bare rest calls from zig.

Structuring the project

Is this a zig project with a web component, vice versa or indeed two independent
parts that work together.

I did a fair amount of web searching to see if there was some guidance I could I
find for a good way to structure a relatively straightforward zig+js project.

I could not find one. In the end, I decided to keep it fairly straightforward.

- shine/
  - src/ # zig code
  - web/ # all the web stuff

Frontend

After a bit of research, and realising that I will probably need a little bit of
supporting content around shine, I decided to go
with lume

I used the simple-blog theme as
a template to start from. I could have just pulled the template in but I wanted
a custom homepage.

When I tried to add an index.md, it complained about two files wanting to
write index.html. From what I could find, the easiest way to override the
homepage was to just pick up the theme and edit it - which was easy enough.

WASM => frontend

I didn't want to copy over the wasm and the js file every time, so I added a
couple of steps to build.zig right after the link_step (also included below)

// build.zig
// create a build step which invokes the Emscripten linker
const link_step = try sokol.emLinkStep(b, .{
    .lib_main = shine,
    .target = opts.mod_main.resolved_target.?,
    .optimize = opts.mod_main.optimize.?,
    .emsdk = dep_emsdk,
    .use_webgl2 = true,
    .use_emmalloc = true,
    .use_filesystem = false,
    .shell_file_path = opts.dep_sokol.path("src/sokol/web/shell.html"),
});
// attach to default target
b.getInstallStep().dependOn(&link_step.step);

// Copy shine.js from default emscripten output
const js_install = b.addInstallFileWithDir(
    b.path("zig-out/web/shine.js"),
    .{ .custom = "../web/src/static/shine" },
    "shine.js",
);
js_install.step.dependOn(&link_step.step);
b.getInstallStep().dependOn(&js_install.step);

// Copy shine.wasm from default emscripten output
const wasm_install = b.addInstallFileWithDir(
    b.path("zig-out/web/shine.wasm"),
    .{ .custom = "../web/src/static/shine" },
    "shine.wasm",
);
wasm_install.step.dependOn(&link_step.step);

These steps will copy across the wasm and the js file across to static/shine.
I wanted to put the js in src/js and the wasm in the static dir. However, the
js file expects the wasm in the same dir. I tried overriding locateFile but it
didn't work.

<!-- index.vto -->
<script>
  window.Module = {
    locateFile: (path, prefix) => {
      if (path.endsWith(".wasm")) {
        return "/static/shine/shine.wasm";
      }
      return prefix + path;
    },
  };
</script>
<script src="/js/shine.js"></script>

I was able to get lume to process the javascript file by adding it.

// _config.ts
site.add("static/shine/shine.js");

Conclusion

With all of these set up, I was able to run:

zig build -Dtarget=wasm32-emscripten --watch

in one window. This command will rebuild wasm and provide it to lume whenever
the zig code changes.

deno task serve

Running this in another window will mean that lume will rebuild on any changes,
including a new wasm file and redeploy. The redeploy will trigger an auto-reload
of the page as well if I have it in a browser.

I now effectively have automated reload with changes if I make changes in either
zig or the frontend.

I don't have hot reload - but this is pretty good for now.

Building Pong in Zig with Raylib – Part 1: Setup, Paddles, and Ball

Shri — Sat, 28 Jun 2025 19:38:29 +0000

Before continuing development on Triangle - my larger, arcade ARPG, factory game, I wanted to take a step back and build something small and familiar. Pong felt like the perfect choice: quick to prototype, easy to understand, and a good warm-up before diving deeper into raylib again.

This post goes alongside my video on YouTube , and walks through the early steps of the project: setting up the game, getting something on screen, and implementing the paddles and the ball.

Why Pong?

Sometimes, before getting deeper into a project, it helps to do something simple just to get your hands moving again. I hadn’t written Zig in a couple of weeks, and wanted a fast feedback loop to:

Get back into using raylib-zig
Have a bit of fun
Remind myself why I made certain decisions in the first place

Project Setup

I’m using raylib-zig for this. You can scaffold a new project with:

./project_setup.sh <project-name>

You could also use zig init and then add the dependency in manually if you prefer.

Drawing the Playground

The Pong “arena” is simple:

Two paddles
A ball (currently static)
A center dividing line
Placeholder for scores

Implementing Paddles

The paddles have:

A position (top-left corner)
A fixed size
A simple render function

const std = @import("std");
const rl = @import("raylib");

const Paddle = @This();

pos: rl.Vector2,

pub fn init(x: f32) Paddle {
    return .{ .pos = .{
        .x = x,
        .y = 200,
    } };
}

pub const size = rl.Vector2{ .x = 25, .y = 100 };

pub fn render(self: Paddle) void {
    rl.drawRectangleV(self.pos, size, .white);
}

It might have been nice to be able to have the paddle calculate more of its own values, but the more I think about it, the more it makes sense to keep the logic in paddle simpler.

Ball Placeholder

To wrap things up for this session, I added a static ball in the center of the screen. It has a radius, position, and velocity fields ready to go. Rendering is straightforward:

const std = @import("std");
const rl = @import("raylib");

const Ball = @This();

pos: rl.Vector2,
r: f32 = 16,
vel: rl.Vector2 = .{ .x = 0, .y = 0 },

pub fn render(self: Ball) void {
    rl.drawCircleV(self.pos, self.r, .white);
}

What’s Next

This was mostly about warming up, but the next episode will tackle:

Adding velocity to the ball
Basic collision detection with paddles

I’ll try and think about simplifying paddle logic, especially the awkward symmetry between left and right.

You can find the full source code on GitHub .

See you in part 2!

DEV Community: Shri

Publishing from hugo to dev.to

Goals

Pre-existing Solutions

Using Hugo

Limitations

Define a new content type

Render code blocks as markdown

Render absolute urls

Output

Next Steps

Images

Tags

Automation

Conclusion

Using `locateFile` to have js and wasm in different locations with emscripten

Include emscripten js file

Override Module

Closing

Calling Javascript from Zig through WebAssembly

Goals

Options

library.js / mergeInto

EM_JS / EM_ASM

EM_JS directly through zig [unsuccessful]

Next steps

Auto reload WASM with zig+lume

Libraries

Graphics

UI

WASM first

Structuring the project

Frontend

WASM => frontend

Conclusion

Building Pong in Zig with Raylib – Part 1: Setup, Paddles, and Ball

Why Pong?

Project Setup

Drawing the Playground

Implementing Paddles

Ball Placeholder

What’s Next

Links

Override `Module`

`library.js` / `mergeInto`

`EM_JS` / `EM_ASM`

`EM_JS` directly through `zig` [unsuccessful]