DEV Community: TheoForger

Closing the Chapter - Recap

TheoForger — Thu, 17 Apr 2025 19:55:24 +0000

It's finally the end of semester. This also marks the end of the second open source course for me. Looking back, there are a lot to reflect on.

Looking at my entire program thus far. I can comfortably say I've learned much more in these two courses than everything else combined. As I mentioned in last semester's recap, learning to code from school feels very "fragmented". It's like you collected all these puzzle pieces but don't have a reference picture to follow. Open source was just the epiphany I needed to make sense of these concepts as a whole.

I've learned so much from these two courses. And it goes way beyond just coding skills too. I can't possibly cover everything here, but I'll go through some of them.

🦀 My Rust Journey

I started learning Rust about two years ago, way before I took this course. However, I was mostly following YouTube tutorials and copying whatever they did. I loved the language, and it was a lot of fun, but without actually building something with the language, it was hard to get a sense of the hows and the whys of the mechanics.

It wasn't until the Mastermind project which I created for the previous course, that I really started to understand Rust. Because I was starting a project from scratch, I had to pay attention to things like design patterns, modules, access control, but also details like memory management, pattern matching syntax, where I really learned to appreciate the ownership system in Rust.

Working on something tangible gave me the incentives to keep learning and improving my code, instead of just aiming to finish an assignment. During that couple of months, I studied more about traits and generic types in my own time, so that I could use them in my project. I also familiarized myself with the Rust ecosystem, like rustup, cargo, and clippy. All these wonderful first-party tools that made Rust a blessing to work with.

The second push was me getting into the Hurl project. This was where I got to know Rust in action. Looking at the GitHub search result, I have submitted 15 PRs in Hurl's repo, with more to come in the future. For each of them, I went all in with code reading, researching, learning. I was exposed to all kinds of technologies like Rust, libcurl, and the HTTP protocol. This is not only a much more valuable experience than learning at school, but also more rewarding.

⚒️ Working With Git and GitHub

Another great skill I learned was Git. I used to have this mindset (I'm sure many others do too) that Git was just there to make your life more miserable in exchange for a respawn point when you completely f*ed up your code. According to my professor, most programmers are not comfortable with Git, some of which claiming that their code is "lost" in it.

Throughout these two semesters, I worked a lot with Git. For my own projects, for my teammate's projects, and for other projects I contributed to. I went from "pushing and pulling from main" to having git checkout, git merge and git rebase in my daily vocabulary. Using these commands now feels like a second nature. Of course, there are still situations where I feel lost, but I learned not to panic about it. With enough patience and some digging with git log or git reflog, I can always find my way back eventually.

I also got quite comfortable with GitHub. Whether it's creating issues, making pull requests, or reviewing code, or making followup changes to a review. I learned to communicate asynchronously with maintainers: Always provide enough context, and respond with actionable comments. In addition, I worked extensively with GitHub Actions to set up CI/CD pipelines on my own project, and to test my code for projects I contributed to.

All these are valuable lessons I could never have learned from lectures and assignments.

❤️ Personal Takeaways

This semester definitely had its ups and downs. There were times I felt like I achieved a lot, and times where everybody seemed to be stuck or distracted. But overall, I am very proud of my continuous work on Hurl, as well as the efforts I put into maintaining Starchart.

Getting into a project was the hardest part. You had to assess the project enough to make sure they welcome contributions, and read the issues enough to find something you can work on, and then understand the code enough to work on these issues. Finally, you had to fight your inner demons and work up your courage to submit your first PR - Then it gets easier from there, but it's always hard at the beginning.

Despite some improvements compared to the very beginning, I still don't feel good about my demos. Something about talking in a conference call makes my thoughts incredibly disorganized. I forget to slow down, forget to breath, and sometimes forget my lines completely.

Last but not the least, I want to say thank you to my wonderful professor David. You have your way of inspiring your students by encouraging us to work on what we're interested in. You gave us freedom to explore and experiment on our own, but also support when we needed it. It's not an exaggeration to say these two courses have been life changing for me, and none of this was possible without you!

That's it folks. See you again in open source!

Sprint 5 - Chakra UI v3 Migration

TheoForger — Wed, 16 Apr 2025 20:59:58 +0000

For the last sprint I focused on Starchart since I haven't got a response from Hurl just yet. This week I saw more and more CVEs popping up for Chakra UI v2's dependencies So I gave it a second attempt to migrate to v3. Spoiler alert: It was a nightmare.

[WIP] Upgrade chakra-ui to v3 #895

theoforger posted on Apr 03, 2025

Description

chakra-ui version 3 introduced many breaking changes. This PR is an attempt to upgrade

Changes

Removed @emotion/styled, framer-motion, @chakra-ui/icons(migrated to react-icons since chakra stopped supporting their icons library)
Modified tsconfig.json to target ESNext.
Add code snippet from chakra
Refactored theme to use systems instead
Changed component names and structures (the migration guide is not complete on this matter)
Dropped useToast hook in favor of toaster from the code snippet

View on GitHub

What Changes Did I Encounter?

In short, everything has changed. From dependencies, components, props, to syntax, configuration schema, even font size and theme. It was essentially a rewrite.

Dependencies

Chakra UI v3 doesn't rely on framer-motion for animation anymore. It needed to be removed, among some other changes

npm uninstall @emotion/styled framer-motion
npm install @chakra-ui/react@latest @emotion/react@latest

They also introduced some code snippet to supplement some of the changes in this update. I'll go through them later, but here's how you add the snippet:

npx @chakra-ui/cli snippet add

Component Names and Behavior

Component Changes happened all across the board. Generally, namespaces are used to replace child components. Some are simple name changes, for example:

v2	v3
<TableContainer> <Table> <Thead> <Tr> <Th/> </Tr> </Thead> <Tbody> <Tr> <Td/> </Tr> </Tbody> <Tfoot> <Tr> <Th/> </Tr> </Tfoot> </Table> </TableContainer>	<Table.Root> <Table.Header> <Table.Row> <Table.ColumnHeader /> </Table.Row> </Table.Header> <Table.Body> <Table.Row> <Table.Cell /> </Table.Row> </Table.Body> <Table.Footer> <Table.Row> <Table.Cell /> </Table.Row> </Table.Footer> </Table.Root>

<TableContainer>
  <Table>
    <Thead>
      <Tr>
        <Th/>
      </Tr>
    </Thead>
    <Tbody>
      <Tr>
        <Td/>
      </Tr>
    </Tbody>
    <Tfoot>
      <Tr>
        <Th/>
      </Tr>
    </Tfoot>
  </Table>
</TableContainer>

<Table.Root>
  <Table.Header>
    <Table.Row>
      <Table.ColumnHeader />
    </Table.Row>
  </Table.Header>
  <Table.Body>
    <Table.Row>
      <Table.Cell />
    </Table.Row>
  </Table.Body>
  <Table.Footer>
    <Table.Row>
      <Table.Cell />
    </Table.Row>
  </Table.Footer>
</Table.Root>

However, many of them also has different behavior and expect different structures. For instance:

v2	v3
<Tabs> <TabList> <Tab>One</Tab> <Tab>Two</Tab> <Tab>Three</Tab> </TabList> <TabPanels> <TabPanel> <p>one!</p> </TabPanel> <TabPanel> <p>two!</p> </TabPanel> <TabPanel> <p>three!</p> </TabPanel> </TabPanels> </Tabs>	<Tabs.Root> <Tabs.List> <Tabs.Trigger value="one"> one </Tabs.Trigger> <Tabs.Trigger value="two"> two </Tabs.Trigger> <Tabs.Trigger value="three"> three </Tabs.Trigger> </Tabs.List> <Tabs.Content value="one">one!</Tabs.Content> <Tabs.Content value="two">two!</Tabs.Content> <Tabs.Content value="three">three!</Tabs.Content> </Tabs.Root>

<Tabs>
  <TabList>
    <Tab>One</Tab>
    <Tab>Two</Tab>
    <Tab>Three</Tab>
  </TabList>

  <TabPanels>
    <TabPanel>
      <p>one!</p>
    </TabPanel>
    <TabPanel>
      <p>two!</p>
    </TabPanel>
    <TabPanel>
      <p>three!</p>
    </TabPanel>
  </TabPanels>
</Tabs>

<Tabs.Root>
  <Tabs.List>
    <Tabs.Trigger value="one">
      one
    </Tabs.Trigger>
    <Tabs.Trigger value="two">
      two
    </Tabs.Trigger>
    <Tabs.Trigger value="three">
      three
    </Tabs.Trigger>
  </Tabs.List>
  <Tabs.Content value="one">one!</Tabs.Content>
  <Tabs.Content value="two">two!</Tabs.Content>
  <Tabs.Content value="three">three!</Tabs.Content>
</Tabs.Root>

As you can see, Tabs in v2 sequentially maps a from to in , while in v3 it requires a value, in addition to all the name changes.

There are many other changes like these. Unfortunately the only way to handle them is to look at the documentation for both versions and compare the differences.

Props

There are changes in both the name of some props, and what props are expected for certain components.

For one, some boolean typed props now have a simpler name. For example, isOpen became open.

The other type of change is also the more challenging type. For example the <Card> component changed the available variants you can use, and silently dropped support for some styling props like align. Some of them are related to some other grand schema changes, but just like the components, the only way to figure them out is to compare the documentation.

Theme Configuration

In Chakra UI v3, themes are included as a part of system, as apposed to a standalone configuration option in v2. The new theme object expects a completely different schema too.

In addition, component-specific style override in v2 is replaced by recipes.

So for the Starchart project, the configuration went from:

const theme = extendTheme(
  {
    styles,
    colors,
    breakpoints,
    components: {
      Link: defineStyleConfig({
        baseStyle: {
          color: 'brand.500',
          textDecor: 'underline',
        },
      }),
    },
  },
  withDefaultColorScheme({ colorScheme: 'brand' })
);

const theme = createSystem(defaultConfig, {
  theme: {
    recipes: {
      link: defineRecipe({
        base: {
          textDecor: 'underline',
        },
      }),
    },
    tokens: {
      colors,
      breakpoints,
    },
    semanticTokens: {
      colors: {
        brand: {
          solid: { value: '{colors.brand.500}' },
          contrast: { value: 'white' },
          fg: { value: '{colors.brand.700}' },
          muted: { value: '{colors.brand.100}' },
          subtle: { value: '{colors.brand.200}' },
          emphasized: { value: '{colors.brand.300}' },
          focusRing: { value: '{colors.brand.500}' },
        },
        brand_gray: {
          solid: { value: '{colors.brand_gray.500}' },
          contrast: { value: 'colors.brand_gray.100' },
          fg: { value: '{colors.brand_gray.700}' },
          muted: { value: '{colors.brand_gray.100}' },
          subtle: { value: '{colors.brand_gray.200}' },
          emphasized: { value: '{colors.brand_gray.300}' },
          focusRing: { value: '{colors.brand_gray.500}' },
        },
      },
    },
  },
  globalCss: styles,
});

Toast

In Chakra UI v2, Toast is used via a hook. However, in v3 it's replaced by the toaster code snippet. In the new version, you need to import both Toaster and toaster from the snippet, place the <Toaster /> component somewhere on the page, and then use toaster to trigger them. For example:

import { Toaster, toaster } from '~/components/ui/toaster';
...
  useEffect(() => {
    if (clipboard.copied) {
      toaster.create({
        title: `${title} was copied to the clipboard`,
        type: 'success',
      });
    }
  }, [title, clipboard.copied]);
...
return (
  <>
    // page content...
    <Toaster />
  <>
)

Dropping `chakra-ui/icon`

@chakra-ui/icons is deprecated in Chakra UI v3. There are a couple of replacements but I decided to migrate to react-icons, since it was already in use for other parts of the project.

To migrate, you need to wrap the icon component from your library of choice with <Link>...</Link>. For example:

// Download icon
<Icon fontSize="md" onClick={handler}>
  <FaDownload />
</Icon>

What's Still Broken?

Custom Breakpoints

In Chakra UI, you can define custom breakpoints like so:

const breakpoints = {
  'xs': { value: '20em' },
  'sm': { value: '30em' },
  'md': { value: '48em' },
  'lg': { value: '62em' },
  'xl': { value: '80em' },
  '2xl': { value: '96em' },
};

However, despite including this configuration in my custom theme, I still get type error in places where custom breakpoints are used:

Animation

Animation is broken after this upgrade, possibly due to the deprecation of framer-motion. However, from my testing, the animation issue does not seem to persist once React is updated to 19.

Mobile Layout

Other than some inconsistent breakpoints behavior, some UI elements are not in the correct place in mobile layout. For example:

Before	After

The Real Problem

The most difficult aspect of this migration was not the changes themselves. It was the lack of documentation for them. Although they provide a migration guide, it's far from complete.

Just to name a few:

The guide doesn't cover most changes in the component names. Some components have completely overhauled their structures (For example <Tabs>), and it's not mentioned either.
Many components changed the props they expect, most of which are not mentioned in the guide.
<Toast> went from a hook to a code snippet, and it's not mentioned.
Font sizes are completely changed, which is not mentioned in the guide.
<Hide> component is removed and the behavior changed in <Show> as well. Neither of them is documented.
Component-specific style override is replaced by recipes. It's not covered by the guide. ...

Of course, this section is not meant as an attack on the Chakra UI project, but a reminder that a significant upgrade like this really needs a comprehensive migration guide. An automation tool would also be nice, like what React did with react-codemod.

Sprint 5 - Mischief Happens

TheoForger — Thu, 27 Mar 2025 14:39:08 +0000

This week I did some more incremental work on Hurl, finalizing the redirects query. On Startchart, I messed up a couple of things, fixed a couple of things and learned a couple of lessons!

Hurl

Add query for HTTP redirects (Link)

Last week, I enabled the code to pass down necessary information about HTTP redirections to queries. Continuing on that, I've been working on the redirects query itself.

Going back to the expected behavior proposed by the maintainer:

GET http://foo.com
HTTP 200
[Asserts]
redirects count == 2
redirects nth 0 url == "http://bar.com"
redirects nth 0 status == 302
redirects nth 1 url == "http://baz.com"
redirects nth 1 status == 302
url == "http://baz.com"

The query is treated like a list, you can perform assertions on the list itself, or get the individual HTTP redirect by index, and then assert on that.

Looking at the code one more time, they already had a Value::List(Vec<Value>) variant, and queries like count and nth were already implemented, so all I had left to do was to create another Value variant for HTTP redirection.

// `runner::HttpResponse`
// Name suggested by the maintainer 
pub struct HttpResponse {
    url: http::Url,
    status: u32,
}

and then

pub enum Value {
    ...
    HttpResponse(runner::HttpResponse),
    ...
}

And then came my favorite part about working in Rust, which was when the compiler told me everywhere else that needs to be changed.

For the evaluation method itself, a.k.a. the place where everything came together, I processed the passed-down responses into runner::HttpResponse. I popped the final response which was not considered a redirect. And finally, I constructed them into a Value::List. Here's the result:

fn eval_redirects(responses: &[&http::Response]) -> QueryResult {
    let mut values: Vec<Value> = responses
        .iter()
        .map(|r| Value::HttpResponse(HttpResponse::new(r.url.clone(), r.status)))
        .collect();
    values.pop();
    Ok(Some(Value::List(values)))
}

Startchart

Some `package-lock.json` Shenanigans

Never merge anything without testing first.

Last week, I merged a PR from my co-maintainer Uday. I didn't think it needed more testing since I had already reviewed it before, and there was only a rebase since then. Plus, the CI pipelines were all green.

Only after that did I realize, although the production build worked just fine, I couldn't run the dev build anymore. There were errors about missing dependencies:

...
node:internal/modules/cjs/loader:1244
  const err = new Error(message);
              ^

Error: Cannot find module 'colorspace'
...

I made a new clone of the project and set up everything from scratch. Still the same result. I messaged Uday to confirmed it. And or course, it worked on his machine 😆. We decided to revert the PR and investigate.

We spent the next couple of hours trying to reproduce and fix this, and eventially we narrowed it down to package-lock.json: We were only able to properly run the dev build if we used npm -ci instead of npm -i.

Then Uday had the idea to simply delete the lock file and re-generate it. We tried it and it worked! This time, of course, I learned the lesson and carefully tested everything.

Update on React hydration errors

Ever since this issue was created, I'd never been able to recreate it. I tried different browsers, different builds - nothing.

This came as a happy accident. I once left the site open overnight, and when I came back, all the stylesheets were gone! I immediately opened up the console. The first thing I noticed: There wasn't any warning of CSP this time.

Comment for #845

theoforger commented on Mar 21, 2025

I finally ran into this issue after leaving the "DNS records" page open and idle overnight. And other pages seemed to load just fine. It might not be related to CSP after all, since I didn't see the error message here.

Strangely, every time I refresh, the style sheet seems to load for a split second and then unloads itself:

https://github.com/user-attachments/assets/0299d9f7-9fe4-43fc-aa18-38320533542f

View on GitHub

I couldn't quite figure out what happened but I decided to look into the behavior even more. Here's what I found:

The stylesheet was only broken on this particular page a.k.a. /dns-records
Every time I refresh, the stylesheet loads for a split second and then unloads itself. (Maybe something to do with cache?)
I could navigate to other pages and then back. In this case everything would load normally, but as soon as I refresh, the stylesheet was gone again.

Fix certificate content (Link)

I found this issue a while ago when I was looking into some certificate related issue. In short, the certificate files from the download links didn't have the correct information inside.

I looked into this expecting it to be some edge-case bug. But it really didn't take me long to find the problem inside the download handler:

...
case 'certificate':
        return createResponse(certificate.certificate, `${certificate.domain}.certificate.pem`);
      case 'privateKey':
        return createResponse(certificate.privateKey, `${certificate.domain}.privkey.pem`);
      case 'chain':
        return createResponse(certificate.certificate, `${certificate.domain}.chain.pem`);
      case 'fullChain':
        return createResponse(certificate.certificate, `${certificate.domain}.bundle.pem`);
...

This turned out to be a much simpler fix than I anticipated - The handler was grabbing the wrong content: In case of chain and fullChain, it was serving the end-entity certificate instead.

Sprint 4 - I'm Finally Making Sense of Hurl

TheoForger — Thu, 20 Mar 2025 14:34:39 +0000

It's the end of Sprint 4. I'm happy to say that I finally find my groove working on Hurl. And as usual, I also did some chores on the Starchart project.

🦀🌐 Hurl

This week I've been working towards a feature request to enable queries on HTTP redirects. Same as before, every time I worked on something new, I was faced with all sorts of confusions. But this time I decided to do more code reading and try to understand it even more.

Code Reading

I started with a similar PR, hoping to find some inspiration. Then I quickly realized this PR only focuses on evaluating the queries, and this feature goes beyond that.

Instead, I followed my intuition to a file I already worked on - the HTTP client file hurl::http::client. I wasn't sure if it's related, but I knew that it was involved in this request and response process. Using the IDE, I followed the trail of where each function was used and eventually constructed a few diagrams to help me understand things:

The diagram above illustrates the basic process of everything involved from the moment when the Hurl file is parsed, to when HTTP requests are made. The green blocks represent function calls, and the red ones are for return values.

Hurl files are first parsed into entries. Each entry contains one call if there's no redirections, or multiple calls if there is. And each call contains a pair of HTTP request and response.

Hurl uses the final call in Vec<Call> to further evaluate information for captures and asserts. The diagram above only shows the capture evaluation process, but assert is similar.

This is a (partial) diagram of the data structures involved in the previous process.

Working on the Feature (Link to PR)

In order to evaluate redirections, I need the knowledge of all the HTTP requests made in the whole request chain. Looking at the diagrams, the last place with the said knowledge is entry::run - since Vec<Call> is returned to this function, and each Call only contains one request. In other words, entry::run is probably where I should work on.

Looking at the code, the actual queries are not evaluated until query::eval_query, but the entire chain of Vec<Call>.last() -> http::Response -> response::eval_captures -> capture::eval_capture -> query::eval_query only knows the final HTTP request. I had to figured out a way to pass the knowledge of others down the chain. To achieve this, I thought of 2 solutions:

Comment for #922

theoforger commented on Mar 19, 2025

@jcamiel Hello! I dug into the code quite a bit. Right now, because our response::eval_captures and response::eval_asserts methods accept one HTTP request, we only use the response from the last call: https://github.com/Orange-OpenSource/hurl/blob/95a2cc55dd318a0a24ac0f3c88245883878853a9/packages/hurl/src/runner/entry.rs#L130-L132

Since we need all the HTTP requests in order to retrieve the redirects, I can think of two solutions to this. Let me know which one you prefer (or something else):

Make a helper function to extract all the HTTP responses from a list of calls, and modify response::eval_captures and response::eval_asserts to accept &[&http::Response] instead.
Modify http::Response to include a list of redirections (or a list of references to the previous responses?)

Really appreciate your input 🙏

View on GitHub

The maintainer picked the first one and gave me some extra help. And that was all I needed to work on my first PR!

Clippy Corner

I'm officially making this a segment because every time I work on Rust, clippy always finds a way to improve my code.

This time, I got a warning of #useless_vec due to the usage of &vec![...]

This is useless because the reference operator & implies that I don't need ownership of this vector. And If I don't need ownership, there's no need to use a vector at all! It's a waste of resources. Instead, I should use a slice: &[...]

⭐🗺️ Starchart

This week's work on Starchart is a mix of housekeeping and research.

Update Dependencies (Link)

It's only been two weeks since my last "update dependencies" PR, but we were swarmed by another wave. This time, I upgraded 18 packages without any breakages.

I was stumbled by a failing test cause by dependabot, but quickly figured out the problem: All remix packages need to be updated together, but dependabot tried to update just one.

Looking into MX Records

This one was tricky because the dev server is not deployed anywhere and it's hard to test public-facing services like DNS on a mock server.

With the help of AI (or rather, LLM 👀), I was recommended the aws client, and it worked!

Comment for #852

theoforger commented on Mar 18, 2025

@lilyhuang-github @uday-rana I was able to use the aws client to retrieve the DNS records from the motoserver/moto mock server:

Using this command:

aws route53 list-resource-record-sets --hosted-zone-id <zone-id> --endpoint-url=<url>

I got:

        {
            "Name": "mail.user1.starchart.com.",
            "Type": "MX",
            "TTL": 300,
            "ResourceRecords": [
                {
                    "Value": "10 mail.com"
                }
            ]
        }

Seems like the record is successfully created!

View on GitHub

I did so by pulling up a shell inside the mock server's docker container and installing the aws client in there. Before you tell me this is super illegal, and I can just install the client on my native system, I did it this way because the client comes with a ton of dependencies and I don't really want to mess up my own system because of it. 😆

Investigating the `samlify` Breakage

This package has been broken since version 2.8.11 and we're on version 2.8.10 for now.

I decided upgrade this again and analyze the error message. Here's what I had on the server

Backtrace:
1 www/_include.php:45 (SimpleSAML_exception_handler)
0 [builtin] (N/A)
Caused by: Exception: Invalid value of boolean attribute 'AllowCreate': ''
Backtrace:
6 vendor/simplesamlphp/saml2/src/SAML2/Utils.php:282 (SAML2\Utils::parseBoolean)
5 vendor/simplesamlphp/saml2/src/SAML2/AuthnRequest.php:233 (SAML2\AuthnRequest::parseNameIdPolicy)
4 vendor/simplesamlphp/saml2/src/SAML2/AuthnRequest.php:168 (SAML2\AuthnRequest::__construct)
3 vendor/simplesamlphp/saml2/src/SAML2/Message.php:572 (SAML2\Message::fromXML)
2 vendor/simplesamlphp/saml2/src/SAML2/HTTPRedirect.php:125 (SAML2\HTTPRedirect::receive)
1 modules/saml/lib/IdP/SAML2.php:316 (sspmod_saml_IdP_SAML2::receiveAuthnRequest)
0 www/saml2/idp/SSOService.php:19 (N/A)

Although the error itself is not related to our project, the AllowCreate attribute caught my eye. I first searched for it within our code base. I found nothing there, so I decided to look upstream.

A quick search in samlify's repo brought me to this issue, and it seems like many people are experiencing this issue as well. Luckily, a fix is already on its way.

❤️🧠 A Quick Note on Stress

The past few weeks have been really difficult to navigate. Tasks from school are piling up, and the stress from job searching too. I was worried that I couldn't get much else done in the midst of all that. I guess this blog proved that wrong and I'm proud of it haha. Let's hope that I can keep this momentum forward!

Sprint 4 - TLS Certificates and CSP

TheoForger — Thu, 13 Mar 2025 14:23:42 +0000

Another week of research! This week my focus has been on stagnant issues from the past. I even discovered some new bugs during the process.

Starchart

React hydration errors (Link)

This was a happy accident. A while ago I was looking into how to secure my home server, and came across HTTP Observatory by Mozilla. It's a service that scans the HTTP headers of your website and gives you feedback on security practices.

Here, among other things, I learned about Content Secure Policy or CSP for short. It's an HTTP header that dictates where the website is allow to retrieve each type of content, like scripts, images, stylesheets, etc.

This issue on Starchart was posted by Uday last week. But when I looked at the screenshots, I saw some very familiar errors in the console:

A good security practice with CSP is to restrict the loading of scripts to only 'self' or an nonce value, which is exactly how it's configured here.

I suspect that maybe some code related to styling isn't very stable and get the nonce value wrong. Of course, more investigation is still needed, but it's a good start!

Investigate Let's Encrypt certificate chain change (Link)

I've been wanting to look into this one for a while. The TLS protocol is always something that fascinates me and I've been learning it in my own time, both for my home server and for personal interest.

The issue here is related to TLS certificates. The Starchart project requests certificates from Let's Encrypt, and last year there was a change in their chain of trust. So we want to know what impact it had to our project.

After spending some time renewing my knowledge of TLS, I looked into the official blog from Let's Encrypt There they outlined a few situations where this could be a problem:

Never downloading the chain at all and only serving the end-entity certificate
Never downloading the chain and instead serving a hard-coded chain
Only downloading the chain at first issuance and not re-downloading during renewals. Please ensure that your client does not fall into any of these buckets.

Looking into out code, we always get the full chain from Let's Encrypt and then split it into an end entity certificate and an intermediate chain:

    // fullChain is the public certificate + the intermediate certificate(s) for Let's Encrypt
    const fullChain = await this.#client.getCertificate(this.#order);

    // certificate is the public certificate, chain is the intermediate certificate(s) for Let's Encrypt
    const [certificate, ...chainArray] = acme.crypto.splitPemChain(fullChain);
    const chain = chainArray.join('');

It seems like we are able to mitigate the issue on the server side. However, if someone is still using the old certificates, they would not continue to work. But I don't think there's much we can do here.

Incorrect content in downloaded certificates (Link)

I noticed this during my research the previous one: The download buttons on the certificate managements page give you the wrong certificates. It's a problem in the development build as well as the already deployed production build! I'm genuinely surprised it has gone unnoticed for as long as it has!

To be more specific, there seems to be something wrong with how the website handles intermediate chain for downloads. Although everything shows up under the hidden section just fine, the file always excludes the intermediate CA certificates.

Hurl

New Issue (Link)

This week I haven't been focusing on Hurl that much, but I had my name assigned on this new issue. Here I'll be working on a new query which returns the specs of HTTP redirections.

Similar to my IP address query feature, you should be able to use these specs in Asserts and Capture. Since there can be multiple redirects for one request, there's a new challenge to handle multiple query results in a list.

New Release!

Earlier today they made a new release of Hurl v6.1.0. This release contains everything I've worked on since last year! Now everyone can finally use those features (and think of me while they do 😂)! Here's the official blog.

Sprint 3 - Hello DNS My Old Friend

TheoForger — Thu, 06 Mar 2025 15:28:08 +0000

After a short break, it's time to get back to the second half of this sprint. This time, I worked on a new feature and some maintenance for Starchart, as well as more followup work for Hurl.

🌐🦀 Hurl

Integration Tests and Docs (Link)

As a followup of the previous PRs, this one finally concludes the ip query feature! As I'm getting more familiar with this project, I now know exactly where to look when it comes to docs and integration tests.

However, some tests are still failing due to "patternization": The integration test system checks the output and compares it with an expected value. However, some output information is run time specific. For example, performance metrics and timing information is different for each run. So the output for these data should be patternized:

Original	Patternized
"timings":{ "app_connect":0, "begin_call":"2025-03-05T22:38:53.547654Z", "connect":207, "end_call":"2025-03-05T22:38:53.563185Z", "name_lookup":34, "pre_transfer":248, "start_transfer":15444, "total":15468 }	"timings":{ "app_connect":"<<<\\d+>>>", "begin_call":"<<<.?>>>", "connect":"<<<\\d+>>>", "end_call":"<<<.?>>>", "name_lookup":"<<<\\d+>>>", "pre_transfer":"<<<\\d+>>>", "start_transfer":"<<<\\d+>>>", "total":"<<<\\d+>>>" }

Original

Patternized

"timings":{
  "app_connect":0,
  "begin_call":"2025-03-05T22:38:53.547654Z",
  "connect":207,
  "end_call":"2025-03-05T22:38:53.563185Z",
  "name_lookup":34,
  "pre_transfer":248,
  "start_transfer":15444,
  "total":15468
}

"timings":{
  "app_connect":"<<<\\d+>>>",
  "begin_call":"<<<.*?>>>",
  "connect":"<<<\\d+>>>",
  "end_call":"<<<.*?>>>",
  "name_lookup":"<<<\\d+>>>",
  "pre_transfer":"<<<\\d+>>>",
  "start_transfer":"<<<\\d+>>>",
  "total":"<<<\\d+>>>"
}

However, according to the maintainer, there doesn't seem to be a way to automate this. So fixing it would be manual labor, which is not the end of the world since they don't have many tests like this.

Good News!

In a previous blog I shared my concern that the Hurl project might take a break from contributions. Ho I'm happy to inform that they made an exception for me!

Of course, I totally understand why they made that decision in the first place: There is huge influx of contributions, a planned release, and considering how much care and patience they put into each contribution, it's a lot of work! I'm flattered by this exception made by them, but at the same time, it's reassuring and inspiring to see my work being recognized.

⭐🗺️ Starchart

Update Dependencies (Link)

Of course, it can't be another week on Starchart without some good old dependency updates. This time I really tried to eliminate as many of them as I could:

I knew upgrading to React 19 was going to be painful, since it introduced a ton of breaking changes. However, as I always do with upgrades like this, I tried to upgrade it anyway and see if anything would break. To my surprise, when I tested it locally, other than one small issue regarding the JSX namespace, it just worked!

However, when I filed the PR, I was welcomed with a failed e2e test. Turned out some code is broken in mobile safari browser:

  3 failed
    [Mobile Safari] › test/e2e/certificate-available.spec.ts:66:7 › Certificate Page › Download Certificate 
    [Mobile Safari] › test/e2e/header/header.spec.ts:11:7 › sign out of the account › sign out ─────
    [Mobile Safari] › test/e2e/landing-page.spec.ts:25:7 › Landing Page › DNS Records Instructions Link 
  1 flaky
    [Mobile Chrome] › test/e2e/landing-page.spec.ts:25:7 › Landing Page › DNS Records Instructions Link

Truly an "it work on my machine" moment 😂.

In addition, I attempted to upgrade express to v5. I did notice that version 5 was marked with the "next" tag, but my inner "Arch Linux spirit" was telling me to update anyway! Turned out it wasn't the best decision I've made, as others prefer to stay at v4 for now.

MX Records (Link)

This was the major feature of this sprint! As we frustratingly navigated through various dependency updates and eventually realized that it's a never ending ride, I decided to finally start working on this feature request to support DNS MX records.

Like I said in the title, I had a complicated relationship with DNS. As someone who's battled with internet censorship for many years, DNS has always been the number one pain point no matter which proxy tool I choose. However, at the same time, I can't help but admire the simplicity of it and the critical rule it plays in modern internet infrastructure.

Even though I also had experience managing DNS records for my home server, I've never dealt with MX records before. Research time!

I came across this short article from Cloudflare which explained it well. Like many other common DNS records, there isn't much complexity to it.

example.com	record type	priority	value	TTL
@	MX	10	mailhost1.example.com	45000

In this example, the record essentially says:

Any email destined for the root domain example.com should be delivered to the mail server at mailhost1.example.com. In case this record fails to resolve, look for other records with priority higher than 10. And this record will come into effect in 45000 seconds.

The implementation wasn't too hard either. I modified the prisma schema file to include the MX record type:

enum DnsRecordType {
  A
  AAAA
  CNAME
  MX
  TXT
}

And made sure the value includes a priority as stated in the documentation (I decided to use 10 as the default since priority is irrelevant in this project):

  if (type === DnsRecordType.MX) {
    return '10 ' + value;
  }

Now, the only problem is that, while the unit tests and integration tests can both past, since DNS is pratically a public service and in this case also involves a mail server, I couldn't figure out a way to test if it's actually functional. I already opened a draft PR. Let's hope we can find a solution together!

Sprint 3 - Dependencies Galore

TheoForger — Thu, 20 Feb 2025 15:03:56 +0000

In this sprint, I shifted my focus from Hurl to Starchart. Spoiler alert: Lots of dependencies were involved 👀.

🦀 Hurl

I didn’t make much progress on Hurl this week. However, I did finish the requested changes for my previous PR, which involved adjusting some error handling rules. It wasn’t anything groundbreaking, but I did learn a few new tricks from clippy:

I encountered the errors above after applying a suggestion from the maintainer:

let is_ipv4 = IpAddr::from_str(&value).map_or(false, |ip| ip.is_ipv4())

The goal was to ensure is_ipv4 is true only if the parse result is OK() and the parsed IP address is IPv4. Since we’re dealing with booleans here, clippy suggested using .is_ok_and:

let is_ipv4 = IpAddr::from_str(value).is_ok_and(|ip| ip.is_ipv4());

This accomplishes the same result but makes the code much more readable!

Concern for the Future

I saw a comment from the Hurl maintainer that they are pausing contributor pull requests. Since Hurl is my 80% project, I’m wondering what this means. Should I focus more on Starchart, or perhaps look for something else for the time being?

📃 Starchart

Code Reviews

It was more difficult than I expected—not in terms of technicality, but because I’m still unfamiliar with reviewing code in a new project. I tried to stick to this guide that was shared with us last semester.

Update Remix to v2 #833

At first, I was completely lost. There were random changes all over the place. But by reviewing the commits one at a time, I realized that most of the changes came from a migration tool. I compared them with the PR description, and everything seemed to be in order.

Bump Prisma to 4.16.2 to match @prisma/client #831

It was a simple version bump. However, during the review, I went to Prisma's documentation and found that the cli tool should be installed as a development dependency, which was a helpful discovery.

Add ESLint 9 to support oxlint #834

Since I worked on the same code previously to remove ESLint, it wasn’t too challenging. However, this PR added even more ignore configs than what we already had. So, I asked the author if there was a way to consolidate them into a single source.

Update Dependencies - Part 1 (Link)

In this PR, I used npm-check-updates to update packages with minor version bumps. Expecting no breaking changes, I upgraded everything at once. Of course, it broke 😆. The issue was I couldn’t pinpoint which package caused the problem.

I reverted my changes and applied the updates one by one. Eventually, I discovered that the culprit was samlify. It was surprising, considering it was just a minor version bump from 2.8.10 to 2.8.11. I checked the changelog but couldn’t find any relevant information, so I decided to exclude it from this PR.

Update Dependencies - Part 2 (Link)

Learning from my previous mistake, I upgraded one package at a time in this round. Since I was dealing with major version updates, I made sure to check the changelog beforehand.

I encountered only two breaking changes: For husky, I found a migration guide in the release notes. For isbot, they also outlined the breaking changes. Both were simple syntax adjustments, nothing too complex.

I also got stuck with prisma. Every time I updated it, the project would break and throw errors. Some quick research revealed that I needed to run prisma generate each time I changed versions.

Results

After the two rounds of updates, the list of outdated packages looked much cleaner:

Before	After

As for the breaking packages, I created an issue to track them.

🤔 Some Thoughts on Dependencies

I had a chat with Uday recently, and he voiced a concern that we’re spending too much time on dependency updates.

And he’s right. We’ve been going back and forth on dependencies for quite a while now: discussing whether we should maintain certain dependencies out of frustration, dealing with dependencies that randomly break things with unclear changelog documentation, and handling unmerged dependency updates that block further updates or new features...

Does managing dependencies really take this much time? Is it just because we were assigned to an outdated project? Is there a better way to handle dependencies so we don’t have to fight with them so much?

Sprint 2 - Picking Up the Pace

TheoForger — Thu, 13 Feb 2025 15:37:18 +0000

This is the end of Sprint 2. This Sprint has gotten me into a lot of joy and pain, and let me tell you all about it.

🪄 Hurl

Support ip query for getting resolved response IP #3106

jcamiel posted on Aug 01, 2024

A proposal to add an ip query

GET https://foo.com
HTTP 200
[Asserts]
ip == "192.168.0.1"

GET https://foo.com
HTTP 200
[Asserts]
ip matches /2001:0000:130F:0000:0000:09C0:876A:\d*/

In libcurl the corresponding call is CURLINFO_PRIMARY_IP.

There is also a CURLINFO_LOCAL_IP but I've the impression that user expectation is more on primary ip.

Question: what's about port ? Does the query ip exctract the IP address and the port (192.168.0.01:8080), or do we have a separate port query that we can do latter?

GET https://foo.com
HTTP 200
[Asserts]
ip == "192.168.0.1"
port == 8080

With ip/portas separated queries, we can also have isIPv6 and isIPv4 predicates:

GET https://foo.com
HTTP 200
[Asserts]
ip isIPv6

Idea from @lepapareil 😎

View on GitHub

This week I've been working to implement this feature to enable hurl users to assert on IP addresses for each request. Since there were quite a few things to do, I decided to break it into multiple PRs.

Add ip address to http::Response (Link)

This was a continuation from last week's research. To make the asserts work, first I had to capture that from libcurl and include it in Hurl's Response module.

To achieve that, I used the method primary_ip provided by the curl crate. There was some issues regarding the return type of this method and the implementation of type conversions, but we worked it out during the previous Sprint.

Other than that, nothing much happened in this PR. There was some changes regarding names and documentation, but it was merged quickly after.

Allow assert on ip address (Link)

After last week's discussion, we decided to simply use the string type to handle ip address queries in the Hurl file. At that point I didn't really understand much of the code, but I was able to find a similar query option : url. Imitating the code, I was able to create a new query entry.

For example:

fn url_query(reader: &mut Reader) -> ParseResult<QueryValue> {
    try_literal("url", reader)?;
    Ok(QueryValue::Url)
}

became:

fn ip_query(reader: &mut Reader) -> ParseResult<QueryValue> {
    try_literal("ip", reader)?;
    Ok(QueryValue::Ip)
}

To my surprise, when I tested it afterwards, everything worked! ==, matches or contains... All the keywords was properly working. Turned out Hurl already had the code to handle all string typed queries generically, so all I had to do was creating the query and plugging it right in. Super cool!

Allow asserts on ip versions (Link)

This was technically a different feature but it was still a part of the original issue. In this PR, instead of treating the IP address as a string and query on the text content, I had to figure out way to evaluate the IP version.

The maintainer suggested to simply take the IP query strings and convert them to std::net::IpAddr. Since this is an enum built-in with the V4 and V6 variants, if the conversion succeeds, I could match the pattern to get the IP version.

However, this task was not nearly as straightforward as the last PR. Since I didn't fully understand the code, I had a very difficult time locating where I even implement this conversion.

First I was determined to figure this out myself. I sat down and carefully read the code, I drafted a few diagrams to help me understand the workflow. However, in Hurl's file parser, whenever I tried to print something, or use the debugger to display something, I would get a strange-looking structure instead of actual text like so:

I was beyond confused. I had to ask the maintainer about this. Turned out they were using something called an AST (abstract syntax tree). This structure maps the relative locations of each section of the file without actually parsing them. You can read more in the maintainer's comment.

With that knowledge in mind and a bit more research, I finally was able to implement this feature. Now I'm still going back and forth with the maintainer regarding error handling, but I'm sure this feature will land soon!

💫 Starchart

Update @aws-sdk/client-route-53 (Link)

I was looking at Starchart yesterday and saw a list of pull requests opened by dependabot, one of which had a failed CI check. I decided to look in a little further. This pull request attempted to update the package @aws-sdk/client-route-53 from 3.360.0 to 3.744.0. That's quite a bit gap in version numbers.

The CI pipeline failed because of a type mismatch. I started by checking the changelog but I didn't notice any changes regarding types.

Fortunately, my IDE was able to help me with locate two new types introduced in the new version:

RRType	ChangeAction
/** * @public * @enum / export declare const RRType: { readonly A: "A"; readonly AAAA: "AAAA"; readonly CAA: "CAA"; readonly CNAME: "CNAME"; readonly DS: "DS"; readonly HTTPS: "HTTPS"; readonly MX: "MX"; readonly NAPTR: "NAPTR"; readonly NS: "NS"; readonly PTR: "PTR"; readonly SOA: "SOA"; readonly SPF: "SPF"; readonly SRV: "SRV"; readonly SSHFP: "SSHFP"; readonly SVCB: "SVCB"; readonly TLSA: "TLSA"; readonly TXT: "TXT"; }; /* * @public */ export type RRType = (typeof RRType)[keyof typeof RRType];	/** * @public * @enum / export declare const ChangeAction: { readonly CREATE: "CREATE"; readonly DELETE: "DELETE"; readonly UPSERT: "UPSERT"; }; /* * @public */ export type ChangeAction = (typeof ChangeAction)[keyof typeof ChangeAction];

RRType

ChangeAction

/**
 * @public
 * @enum
 */
export declare const RRType: {
    readonly A: "A";
    readonly AAAA: "AAAA";
    readonly CAA: "CAA";
    readonly CNAME: "CNAME";
    readonly DS: "DS";
    readonly HTTPS: "HTTPS";
    readonly MX: "MX";
    readonly NAPTR: "NAPTR";
    readonly NS: "NS";
    readonly PTR: "PTR";
    readonly SOA: "SOA";
    readonly SPF: "SPF";
    readonly SRV: "SRV";
    readonly SSHFP: "SSHFP";
    readonly SVCB: "SVCB";
    readonly TLSA: "TLSA";
    readonly TXT: "TXT";
};
/**
 * @public
 */
export type RRType = (typeof RRType)[keyof typeof RRType];


/**
 * @public
 * @enum
 */
export declare const ChangeAction: {
    readonly CREATE: "CREATE";
    readonly DELETE: "DELETE";
    readonly UPSERT: "UPSERT";
};
/**
 * @public
 */
export type ChangeAction = (typeof ChangeAction)[keyof typeof ChangeAction];

This part of the code is responsible for managing DNS records. RRType defines the type of DNS record and ChangeAction defines the type of changes to perform on an existing record. While all these types were previously represented by string.

I changed the code to the new types and filed a PR. Later the review came back, suggesting that I create a utility function to handle the type conversion. And this is where I'm at right now.

📝 Conclusion and What's Next

This Sprint felt much more eventful than the last one. In the Hurl project, I was working on a different area of code, which means that more time were spent on search and asking questions. I also made more mistakes because of this unfamiliarity. On the Starchart's side, although I haven't taken much action yet, I suspect there to be more to come:

For the next Sprint, I might need to dial back a little on the Hurl project, since the maintainer mentioned that they have stopped taking in new features until the next release (6.1.0). So my plan is to pick a few bugs to investigate there, while shifting my focus a little more to Starchart.

Sprint 2 - Getting Stuck A Little

TheoForger — Thu, 06 Feb 2025 13:52:29 +0000

This week I've mostly been working on this issue from Hurl. It proposes a new feature which allows users to query the IP address of the response and assert on it.

Support ip query for getting resolved response IP #3106

jcamiel posted on Aug 01, 2024

A proposal to add an ip query

GET https://foo.com
HTTP 200
[Asserts]
ip == "192.168.0.1"

GET https://foo.com
HTTP 200
[Asserts]
ip matches /2001:0000:130F:0000:0000:09C0:876A:\d*/

In libcurl the corresponding call is CURLINFO_PRIMARY_IP.

There is also a CURLINFO_LOCAL_IP but I've the impression that user expectation is more on primary ip.

Question: what's about port ? Does the query ip exctract the IP address and the port (192.168.0.01:8080), or do we have a separate port query that we can do latter?

GET https://foo.com
HTTP 200
[Asserts]
ip == "192.168.0.1"
port == 8080

With ip/portas separated queries, we can also have isIPv6 and isIPv4 predicates:

GET https://foo.com
HTTP 200
[Asserts]
ip isIPv6

Idea from @lepapareil 😎

</div>
<div class="gh-btn-container"><a class="gh-btn" href="https://github.com/Orange-OpenSource/hurl/issues/3106">View on GitHub</a></div>

I decided to really break it down into smaller PRs since there's going to be quite a lot of work to do.

As expected, since I'm moving into a new territory of the project, this would be a bumpy start. Luckily the maintainer gave me some guidance to work with.

🔧 Modify the `Response` Module (Link)

The first step was to modify the Response module. This was surprisingly easy: I added an ip_addr field to the Response struct and followed the breadcrumb of the Rust compiler. Quickly, I was able to figure out where the code should go.

One issue with it was that libcurl only gives you a string slice (&str) of the IP address. So if I want to store it using the standard library enum std::net::IpAddr, you have to convert it, and this conversion could fail. The maintainer suggested we create an intermediate struct for the response module, and only convert it if it's necessary. This way, if the user doesn't have any assert on IP address, there wouldn't be any run time error even if the address is invalid.

We had some more discussion on the specifics, but nothing major happened afterwards.

📝 (Attempt to) Implement IP Address Asserts

The Asserts field in Hurl allows you to specify conditions which the response has to meet. It's an extremely useful feature for testing.

I used a similar strategy as a start - I found an enum called QueryValue that seemed like it had to do with asserts, so I added another variant QueryValue::Ip, and then I followed the compiler's messages. The problem this time was that, the messages took me all over the project and I was completely lost. It was so overwhelming that I had to pause.

Feeling confused, I spent quite some time reading the code. Although I still can't say I fully understand it, I made a simple diagram to help me visualize it:

Obviously, this is overly-simplified and may not even be correct. But the idea is that some kind of information is taken from both the response and the Hurl file. Then they are processed into results and asserts are performed between these results.

After some tinkering, I had the basic assert feature working:

There's still problem: As a part of the feature request, the maintainer wants to also be able to assert the IP version , i.e. IPv4/IPv6. In this context, it makes more sense to model these queries into std::net::IpAddr, since it's an enum with already built-in variants IpAddr::V4 and 'IpAddr::V6'. However, in order to support certain assert features like contains or matches, these queries have to be strings.

Another issue was with IPv6 abbreviation. For example:

2001:0DB8:0032:0000:0000:0000:0000:FFFF
2001:0DB8:0032:0:0:0:0:FFFF
2001:0DB8:32:0:0:0:0:FFFF
2001:DB8:32::FFFF

All of the above are the same IP address. If we want to implement it as a string, users might not know what type of abbreviation to expect

I posted another comment about this situation and this is where I'm at right now. Let's see what the maintainer would say 😆

Sprint 1 - Research Time!

TheoForger — Sat, 01 Feb 2025 04:34:52 +0000

Our first 2-week sprint came to an end. During this week, not much happened code-wise. However, working on these projects had led me to some interesting findings. And I'll be sharing all that right here!

🌐 Hurl

(Link to PR)

This would be my last PR regarding the header option feature. And I'm happy to report that I'm officially responsible for and in charge of this feature 🤪!

This PR was essentially the reverse of the previous one. This time, my contribution was to hurlfmt. This tool, among other features, allows you to convert curl commands to hurl files. I enabled it to handle empty headers in this process. For example, if you prepare a file named example:

# file: example
curl --header 'Empty-Header;' https://httpbin.org/status/200

and run:

$ hurlfmt --in curl example

You'll get the same request in hurl file format (Notice that ; is replaced with :):

GET https://httpbin.org/status/200
Empty-Header:

Rust Stuff

Something interesting I encountered with clippy: In my initial implementation, I used a combination of ends_with() and slicing, like so:

for header in headers {
    let trimmed_header = header.trim();
    if trimmed_header.ends_with(";") {
        s.push_str(format!("\n{}:", &trimmed_header[..trimmed_header.len() - 1]).as_str());
    } else {
      ...
    }
}

And once again, the Rust toolchain took babysitting to another level:

The suggested fix used the if let pattern matching syntax and the strip_suffix method. If the header ends with an ;, it will match Option::Some, and then I can use the stripped string for the new format. Perfect! I appreciate how the linter always encourages you to do things "the Rust way".

Time to Investigate!

During my development, I discovered a bug where if I use a file like the example above, hurlfmt would simple panic. Later, I realized that it happens to any invalid headers. I decided to look into this.

Time to use the good old debugger! After many breakpoints and step-overs, I narrowed down the cause to the request parser. Seems like if a header is not parsed properly, the parser would terminate early and assume the rest belongs to a different request. And of course, the text that follows does not actually define a new request - This causes the program to panic.

To better explain this, I ran hurlfmt twice and recorded the cursor positions after parsing the requests. Here are the results:

With a valid header	With an invalid header

The parser terminated at the end of the text	The parser terminated early

And if we look closer, we can find that the parser stopped right before the invalid header. Here's index 55 in the buffer:

Since this part of the code was complete new territory to me, I filed an issue and hoped the maintainers would have more ideas about this. So far there haven't been any updates. But we'll see how this goes.

🌠 Starchart

(Link to PR)

After last week's decision to switch from ESLint to Oxc, I've been doing research. For the most part, this is a very straightforward project. I simply removed all the ESLint dependencies and added oxlint to the list. Everything seemed to work, mostly.

To migrate the configurations, I referred to their official documentation. The Ocx linter has a very similar configuration file to ESLint. For the most part, I just copied over the specs from the original file, except for this one section:

  extends: [
    '@remix-run/eslint-config',
    '@remix-run/eslint-config/node',
    'plugin:playwright/playwright-test',
    'prettier',
  ],

Apparently, Oxc still doesn't support the extend option. Although the linter runs just fine without it, I'm not sure if this will lead to any problems in the future.

Plans for Sprint 2

Hurl - Support ip query for getting resolved response IP

(#3106)
For this issue I'll implement a new feature to allow users to assert the IP address for each response. This is going to be a new chapter for me since I'll be working on a different part of the project. I spent the last few months with options and requests, but this will be all about responses. Can't wait to find out what I'll learn next!

Starchart - ???

Since this is my 20% focus and I'm not super familiar with this project, I asked the class for recommendations during this week's sprint meeting. The professor mentioned there's a bug where certain CSS doesn't load. However, there's no recorded steps to reproduce. I'll work with the other folks on this project and see if we can figure out the cause.

Sprint 1 - So Far so Good

TheoForger — Fri, 24 Jan 2025 23:17:40 +0000

It's the first week of our first sprint! I can feel the pace picking up. Love it! Here's the works I've done:

🦀 Hurl

Use variables in integration test (Link)

This was a follow-up from my previous PR. Continuing on the topic of headers, the maintainer suggested me to add an integration test which uses variables to configure headers.

I actually didn't know this feature until then. I am always amazed by the niche features that Hurl has to offer. I guess the surprises just kept on coming! Essentially, you can have a hurl file like this:

GET https://example.org/
[Options]
header: {{my_header}}

GET https://example.com/
[Options]
header: not-from-variable
...

and execute hurl with --variable:

$ hurl hurl_file.hurl --variable my_header=from_variable

This way, you can apply headers to certain requests without having to type it out under every one of them. Neat!

In this PR, I simply created a new integration test with this syntax, which was merged without any problems.

Allow empty headers (Link)

This was also a follow-up, but from way back. The issue was created back when I was adding the --header option. In a comment, I expressed my confusion about the behavior if the header is empty. Later it evolved into a conversation between the maintainers and then the said issue.

In case you don't know, here's how curl(as well as libcurl) handles it:

Remove an internal header by giving a replacement without content on the right side of the colon, as in: -H "Host:". If you send the custom header with no-value then its header must be terminated with a semicolon, such as -H "X-Custom-Header;" to send "X-Custom-Header:"

However, the maintainers of Hurl decided that they would not keep this consistent with curl. Instead, they wanted to use Header: to simply set an empty header. If the ability to remove headers is needed, they could implement it as a separate option in the future.

Other than this feature tweak, there's also a --curl option in Hurl to convert hurl file specs to curl commands. Because of this change in behavior, I also added some code to make sure this feature work as expected.

TLDR: Now you can use --header 'Header:' to set an empty header!

🌌 Starchart

My initial plan with Starchart was to simply update the dependencies. There had been a lot of development in this project this week, but all work was not done by the time I tested it.

First of all, I noticed that despite most vulnerabilities being fixed, most packages were still extremely out-of-date. I randomly decided to update eslint, or at least try to. Turned out there was a series of issues waiting ahead:

As soon as I bumped up the version number of eslint, I was greeted with a message:

Apparently, in version 9, ESLint decided to deprecate the eslintrc configuration method, which this project is using. Since version 8 had already reached its end of life, migration was necessary.

Not a big deal, I thought. I just needed to look up the migration guide. Fortunately, their official documentation had a detailed page on this matter and they even provided a tool to automate this process.

The migration was smooth but I ran into another issue:

So yeah... More deprecation: This time it was the @remix-run/eslint-config package. Looking through their description I realized that this tool relies on the old configuration method, so if I don't deal with this first, I couldn't do anything with ESLint either.

Feeling puzzled, I created an issue asking for more opinions. My professor later chimed in and suggested that we switch to Oxc. He commented that "A tool should work for me, not me for it", which I 100% agree.

I've heard good things about this tool before, and hey, it's written in Rust. How could I say no to that! 😆

👥 Sprint Meeting

During our Thursday meeting we each demoed the progress on our work. Not gonna lie, I was still pretty anxious.

Before the meeting I prepared a sheet with bullet points of what I wanted to say, but during the meeting I found myself not able to read it at all.

During the demo, I caught myself getting lost in my speech. And my only fallback strategy was to tell the story chronologically. This might work in a blog post like this, but not in a presentation - Despite me including a lot of unnecessary details, I still couldn't tell if I got my points across or not.

I think there's still a long way to go before I can be comfortable in this type of meetings, but I'm willing to keep practicing.

Some of the feedback and things I learned:

Bring in more empathy. Think from the listener's perspective. What do they want to know? What do they need to know?
Think about what details are necessary to the audience. Some details might be important to me, but not necessarily to the listeners. Remove those that are not needed.
Try making some simple slides. It might be better than looking back and forth between my screen and paper.
Pre-record or screenshot the work while working on it, and save it for the demo.

Back For More!

TheoForger — Thu, 16 Jan 2025 01:39:38 +0000

It's been a month since my last update. If you're reading this, hope you had a wonderful holiday/new year! It's a new semester, and I'm once again taking a course on open source. Except that this time, instead of the "touch-and-go hacktoberfest-style" contributions, we will stick to a couple of projects and really get involved. Sounds fantastic!

🏃‍♂️ Warm-ups

One of the tasks this week is to try and set up these projects:

💬 ChatCraft.org

Chatcraft is a web application to chat with various LLMs. It's tailored for programmers and supports some coding-specific features which you cannot find from general-purpose LLM providers.

This project is under active development and regularly maintained. It comes with detailed documentation on how to set up the dev environment. For me, it was a very simple process.

It worked just like that! No errors, no endless research and troubleshooting. Not a surprise from a well-maintained project! The only extra work I did was installing the pnpm package manager, which was also easy.

✨ Starchart

According to our professor, Starchart was an old project from our college. Students could use this service to get a free subdomain as well as an SSL certificate. Unfortunately, it was not funded anymore. If only I knew this before, I could've used it for my home server haha.

I set up the docker containers following the contribution guide. And I gotta say, it's always satisfying to watch docker compose do its own thing. Feels like magic!

Because this is an unmaintained project (last commit was from 2 years ago), I almost expected trouble before I even started. To my surprise, I didn't run into much issues here either, other than some warnings of vulnerabilities and deprecation, which was totally expected. Just your typical npm things.

Despite the warnings, the server ran just fine. However, I'd imagine it to be a different story if I were to try and upgrade these packages. There would probably be breaking changes all over.

📃 Plans for The Semester

Last semester, I left off with some unfinished work in the Hurl project. And last week, I finally picked up the last piece of work and submitted a PR for it. To my surprise, it was accepted without any request for change. I felt kinda proud haha 😆.

Other than another followup feature request, I also asked them about potentially continuing my work in the Hurl project for this course, to which they responded positively!

There are lots of issues in this project I want to work on. I believe this is a great opportunity to further my knowledge in the HTTP protocol as well as Rust. It's like a dream come true!

Naturally, this is where I envision myself to spend most of my efforts in. And for a second project, I think I'll go with Starchart - with Hurl, I'll be regularly working on new features, fixing bugs, and writing tests. With Starchart, I'll focus more on maintenance. This way I can have a more balanced experience.

✅ Conclusion

Not gonna lie, I've been excited about this course throughout the entire holiday. Can't wait to get back to it and have more open source in my life 😆

DEV Community: TheoForger

Closing the Chapter - Recap

🦀 My Rust Journey

⚒️ Working With Git and GitHub

❤️ Personal Takeaways

Sprint 5 - Chakra UI v3 Migration

[WIP] Upgrade chakra-ui to v3 #895

Description

Changes

What Changes Did I Encounter?

Dependencies

Component Names and Behavior

Props

Theme Configuration

Toast

Dropping chakra-ui/icon

What's Still Broken?

Custom Breakpoints

Animation

Mobile Layout

The Real Problem

Sprint 5 - Mischief Happens

Hurl

Add query for HTTP redirects (Link)

Startchart

Some package-lock.json Shenanigans

Update on React hydration errors

Comment for #845

Fix certificate content (Link)

Sprint 4 - I'm Finally Making Sense of Hurl

🦀🌐 Hurl

Code Reading

Working on the Feature (Link to PR)

Comment for #922

Clippy Corner

⭐🗺️ Starchart

Update Dependencies (Link)

Looking into MX Records

Comment for #852

Investigating the samlify Breakage

❤️🧠 A Quick Note on Stress

Sprint 4 - TLS Certificates and CSP

Starchart

React hydration errors (Link)

Investigate Let's Encrypt certificate chain change (Link)

Incorrect content in downloaded certificates (Link)

Hurl

New Issue (Link)

New Release!

Sprint 3 - Hello DNS My Old Friend

🌐🦀 Hurl

Integration Tests and Docs (Link)

Good News!

⭐🗺️ Starchart

Update Dependencies (Link)

MX Records (Link)

Sprint 3 - Dependencies Galore

🦀 Hurl

Concern for the Future

📃 Starchart

Code Reviews

Update Remix to v2 #833

Bump Prisma to 4.16.2 to match @prisma/client #831

Add ESLint 9 to support oxlint #834

Update Dependencies - Part 1 (Link)

Update Dependencies - Part 2 (Link)

Results

🤔 Some Thoughts on Dependencies

Sprint 2 - Picking Up the Pace

🪄 Hurl

Support ip query for getting resolved response IP #3106

Add ip address to http::Response (Link)

Allow assert on ip address (Link)

Allow asserts on ip versions (Link)

💫 Starchart

Update @aws-sdk/client-route-53 (Link)

📝 Conclusion and What's Next

Sprint 2 - Getting Stuck A Little

Support ip query for getting resolved response IP #3106

🔧 Modify the Response Module (Link)

Dropping `chakra-ui/icon`

Some `package-lock.json` Shenanigans

Investigating the `samlify` Breakage

🔧 Modify the `Response` Module (Link)