Forem: HichemTech

🚨If You Have an npm Package, Read This Before November 2025

HichemTech — Sun, 12 Oct 2025 22:16:25 +0000

In case you missed it, GitHub just announced a major security update for npm that will start rolling out this October and finish by mid-November 2025.
If you maintain or publish npm packages (even small ones) this update will affect you. And if you ignore it, your next CI/CD publish might suddenly stop working.

What’s Happening

GitHub (which owns npm) is tightening authentication rules to protect the ecosystem from supply-chain attacks.
The update has three main parts:

Shorter token lifetimes

All new granular tokens will expire after 7 days by default (down from 30).
The maximum lifetime is now 90 days — previously it was unlimited :/.

Classic tokens are going away

Over the next five weeks, all legacy classic tokens will be revoked.
You won’t be able to generate them anymore.
They lacked granular permissions and were considered high-risk if compromised.

TOTP 2FA is being phased out

You won’t be able to configure new TOTP-based two-factor setups.
GitHub is moving toward WebAuthn / passkeys for stronger, phishing-resistant authentication.

By mid-November 2025, the old world of “one permanent token forever” will be gone.

Why These Changes Matter

In the past year, npm faced an uncomfortable wave of phishing attacks and compromised packages.
Several maintainers received realistic emails tricking them into giving up credentials, leading to malicious updates pushed to popular libraries through post-install scripts.
At one point, we saw three major incidents in a single week in past september 2025 — a clear sign that npm’s token system needed an upgrade.

Long-lived tokens were an easy entry point for attackers.
By forcing expiration and rotation, GitHub is limiting the damage a stolen token can cause.
This is a necessary evolution, even if it means extra friction for us developers.

What You Need to Do (Before November 2025)

Stop using classic tokens

Generate new granular access tokens with scoped permissions.
Update your CI/CD pipelines, GitHub Actions secrets, and local .npmrc files.

Plan for token rotation

Tokens now live for a maximum of 90 days.
If you publish often, schedule rotation reminders — Google Calendar, Notion, whatever keeps you sane.
Don’t wait until your GitHub Actions fail mid-deploy.

Consider trusted publishing (OIDC)

GitHub Actions and GitLab CI already support it.
No token rotation, better provenance, simpler security.

Stay realistic about grouping tokens

You can group related packages or an organization under one token to reduce clutter, but avoid sharing tokens too broadly — compromise in one repo means risk for all.

Looking Ahead

This isn’t just about compliance — it’s about modernizing npm’s security foundation.
Expect more short-lived credentials, WebAuthn enforcement, and OIDC-based publishing in the future.

We’re moving toward a world where tokens won’t live long enough to be stolen, and where publishing relies on temporary, verifiable credentials from your CI provider.
Yes, it’s one more thing to manage — but it’s also the thing keeping millions of developers safe.

These new npm rules might feel strict, but they’re long overdue — and the sooner you adapt, the smoother your builds will be when November hits.

Shared States in React Have Never Been Easier ;)

HichemTech — Fri, 29 Aug 2025 20:01:40 +0000

Imagine This Situation…

You’re building a React app. You’ve got a counter, a user object, maybe a Firebase subscription. You think, hey I’ll just throw useState in there and I’m good. And then it hits you: what if I need this same state in another component? 😱

Options today?

Context → wrap your whole App.tsx just to share one boolean. Boring. Annoying. Overkill.
Redux → congratulations, you just added 100 lines of boilerplate for 1 variable.
Zustand, Jotai, etc. → cool, but still feels like setting up a store for something that could be a line of code.

So what if I told you that you can have a shared state in React with almost the same simplicity as useState? No providers if you don’t want them, no reducers, no context wrappers, just a tiny hook that feels natural.

That’s what I built: react-shared-states. 🎉

Check it here: react-shared-states

Example: Two Components, One Counter 🕹️

import { useSharedState } from "react-shared-states";

function A() {
  const [count, setCount] = useSharedState("counter", 0);
  return <button onClick={() => setCount(count + 1)}>A: {count}</button>;
}

function B() {
  const [count, setCount] = useSharedState("counter", 0);
  return <button onClick={() => setCount(count + 1)}>B: {count}</button>;
}

function App() {
  return (
    <>
      <A />
      <B />
    </>
  );
}

Click on A’s button → B updates instantly. They’re synced because they share the same key ("counter"). That’s it. No Provider, no boilerplate, no context-hating rants.

This is the heart of the package: shared states that feel like normal states.

How Did This Madness Start? 👀

Story time. A friend of mine was using Firebase and came across a package called useBetween. He loved it: it allowed him to call a hook once, and then reuse the data everywhere. For example:

const users = useBetween(useUsersData);

Perfect for his Firebase use case—load users once, and then just consume them anywhere. He was happy. Until he wasn’t.

He merged his branch and suddenly pnpm peer dependency errors everywhere. His branch was on React 18, but the main repo was updated to React 19. He tried updating, but nothing worked. Why? Because useBetween was abandoned. Even worse, it was using React internals that React 19 removed.

One infamous line from the source code:

const ReactSharedInternals = React.__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED;

Yes, you read that right. The author literally accessed React’s private internals and based the whole package on it. 🚨

My friend had no choice but to throw it away and refactor everything back to… Redux. LMAO. XDD. Can you imagine being forced back into reducers and actions after tasting freedom?

That’s when I thought: Why can’t we have something like useBetween, but done properly?

The Secret Weapon: `useSyncExternalStore`

React actually gives us the right tool for this: useSyncExternalStore. Unlike useBetween, which broke React’s rules, this hook is the official API to subscribe to external stores.

Let me show you a tiny demo:

let counter = 0;
let listeners: (() => void)[] = [];

const subscribe = (listener: () => void) => {
  listeners.push(listener);
  return () => listeners = listeners.filter(l => l !== listener);
};

const getSnapshot = () => counter;

const setCounter = (val: number) => {
  counter = val;
  listeners.forEach(l => l());
};

function Counter() {
  const value = useSyncExternalStore(subscribe, getSnapshot);
  return <button onClick={() => setCounter(value + 1)}>{value}</button>;
}

Clicking the button updates the external counter, notifies all listeners, and React re-renders. It’s just like useState, but the state lives outside React. That’s the magic: shared state, officially supported.

Scopes: Not Everything Should Be Global 🌍

Sometimes, you don’t want everything to be shared globally. That’s where scopes come in.

By default, useSharedState uses the global scope. But you can isolate parts of your app using SharedStatesProvider:

<SharedStatesProvider>
  <Component />
</SharedStatesProvider>

Inside this provider, all shared states are local to that scope. Want to get fancy? You can even give a provider a name so multiple trees (like a modal in a portal) can share the same scope:

<SharedStatesProvider scopeName="modal">
  <ModalContent />
</SharedStatesProvider>
<Portal>
  <SharedStatesProvider scopeName="modal">
    <FloatingToolbar />
  </SharedStatesProvider>
</Portal>

Now your modal and toolbar are in sync, even though they’re in different React trees without having one big context provider. Clean, simple, and powerful.

Async Goodness: Shared Functions ⚡

What if your shared state comes from a fetch? Easy.

const fetchUser = () => fetch("/api/me").then((r) => r.json());

function Profile() {
  const { state, trigger } = useSharedFunction("current-user", fetchUser);

  useEffect(() => { trigger(); }, []);

  if (state.isLoading && !state.results) return <p>Loading...</p>;
  if (state.error) return <p>Error!</p>;

  return <h1>{state.results.name}</h1>;
}

Call trigger() once, and the result is cached and shared everywhere. Another component using the same key ("current-user") gets the result instantly, without refetching. That’s automatic caching and deduplication out of the box.

Subscriptions: Firestore, Sockets, You Name It 🔥

Realtime data? useSharedSubscription is here:

const { state, trigger } = useSharedSubscription(
  "user-123",
  (set, onError, onComplete) => {
    const unsub = firebase.onSnapshot(doc(db, "users", "123"), (snap) => {
      set(snap.data());
    }, onError, onComplete);
    return unsub;
  }
);

useEffect(() => trigger(), []);

if (state.isLoading) return <p>Connecting...</p>;
if (state.error) return <p>Error!</p>;

return <div>{state.data.name}</div>;

The first component sets up the subscription, others just “tap in” and get updates instantly. When no component uses it anymore, it auto-unsubscribes. No duplicate sockets, no memory leaks. 🙌

Static API: Control from Outside React 🛠️

Sometimes you want to set a value or trigger a fetch without being inside a component. That’s why the library exposes a static API:

import { sharedStatesApi } from "react-shared-states";

sharedStatesApi.set("theme", "dark");
console.log(sharedStatesApi.get("theme"));

Great for SSR, debugging, or triggering updates from non-React code.

Wrapping Up 🎁

So that’s the story:

My friend tried useBetween, it broke on React 19 because it hacked private internals.
I thought: why not do the same idea, but properly, using useSyncExternalStore?
After experimenting, I built react-shared-states → a library that gives you shared states, scopes, async functions, subscriptions, and even static APIs, all with React’s blessing.

If you hate boilerplate, if you hate wrapping your app with context providers for tiny values, or if you just want something that works—you’ll love this package.

Because honestly… shared states in React have never been this easy, or this fun. 🚀

👉 Check it out: github.com/HichemTab-tech/react-shared-states

When Composer Met pnpm: The Birth of Pomposer

HichemTech — Mon, 07 Jul 2025 03:03:27 +0000

It was a typical Saturday night, coding away while the rest of the world was probably out having fun or sleeping. Yep, that's me, and if you're reading this, it's probably you too. I was deep into one of my side projects, building an open-source JavaScript tool (you'll probably see it soon, stay tuned! 😉), when I casually hit pnpm install. And, whoosh! Installation completed instantly. No surprise there, right? That's pnpm doing its magic—sharing packages globally, optimizing storage, and making installs lightning fast.

Right after that, I switched gears to a Composer project (my little side project had both backend and frontend). Out of habit, I typed composer install and waited. And waited some more. Composer downloaded everything fresh, even packages I've installed dozens of times. That's when the idea hit me, why doesn't Composer have pnpm's awesome feature?

Alert! 🚨 My brain had officially woken up.

If you know me, you know I love building things out of pure curiosity and the moment's need. Remember my previous adventures like ts-runtime-picker, or when I almost rewrote half of Laravel just to fix my personal issue? Yeah, I get carried away sometimes, but hey, it's all part of the fun (you should check out those stories sometime).

Anyway, back to my Saturday night realization. I decided right then and there, why not build "pnpm for Composer"? Wait, if npm has pnpm, then Composer should have… Pomposer! 😄 Yes, I actually loved that name and ran with it immediately.

Terminal opened:

mkdir pomposer && composer init

Then came the staring at my blank sketchpad. How do we make this happen?

First obvious idea: install packages once in a global folder, let's call it ~/.pomposer-store. Easy right? I quickly tried creating a dedicated folder for each dependency, running composer require individually:

cd ~/.pomposer-store
mkdir monolog/monolog && cd monolog/monolog
composer require monolog/monolog

Yay! Wait… no. 🤔 It installed sub-dependencies too. That's not what I wanted at all. Dependency hell was looming. And to be honest, it was frustrating. How do we get Composer to just install a single package?

I tried different strategies, maybe I could parse the composer.lock file manually and selectively install dependencies? Nah, we don't always have the composer.lock. What about using Composer's internal APIs? Nope, Composer stubbornly refuses to install just one package without dragging along its friends.

Next idea: cloning repositories directly from GitHub? It sounded brilliant at first, but then I realized not every package was on GitHub :"), and managing different git references became messy super fast.

I spent several hours, probably way too many cups of coffee deep, contemplating how Composer works under the hood. After all that caffeine-fueled brainstorming, it finally struck me.. what if we just download packages directly from Packagist as ZIP files? Direct, simple, no Composer command involved:

$url = "https://repo.packagist.org/p2/monolog/monolog.json";
$json = json_decode(file_get_contents($url), true);
$zipUrl = $json['packages']['monolog/monolog'][0]['dist']['url'];
file_put_contents("monolog.zip", file_get_contents($zipUrl));

Wow! It worked perfectly. Packages downloaded separately, no dependency mess. But then, another problem—how do we handle autoloading? Composer generates nice autoload files for us, but now we're doing it manually.

Another round of brainstorming commenced. Regex parsing adventures, many error messages, and a lot more coffee later, the solution slowly emerged—I could read each package's composer.json to generate a unified autoloader dynamically. It wasn't ideal, but it worked:

// autoload_psr4.php
return [
  'Monolog\\' => '~/.pomposer-store/monolog/monolog/src/',
  // other packages
];

And voilà! It worked. 😍 Here's a working example:

Create a simple project with a composer.json:

{
  "require": {
    "monolog/monolog": "^3.9",
    "hichemtab-tech/namecrement": "^1.1"
  }
}

Run Pomposer:

pomposer install

And a quick test file:

<?php
require_once 'vendor/autoload.php';

use HichemTabTech\Namecrement\Namecrement;
use Monolog\Logger;
use Monolog\Handler\StreamHandler;

$existing = ['file', 'file (1)', 'file (2)'];
$newName = Namecrement::namecrement('file', $existing);

echo "Next unique file name after the list of existing files:\n";
echo "Existing files: " . implode(', ', $existing) . "\n";
echo "New file name: " . $newName . "\n\n";

$log = new Logger('pomposer');
$log->pushHandler(new StreamHandler('php://stdout', Logger::DEBUG));
$log->info('Pomposer is alive! 🚀');

Running php index.php outputs:

Next unique file name after the list of existing files:
Existing files: file, file (1), file (2)
New file name: file (3)

[2025-07-06 20:31:22] pomposer.INFO: Pomposer is alive! 🚀 []

Yes, Pomposer lives! But hold on, we're still in super-early beta. It has no Composer plugin support, no dev dependencies yet, no scripts or fancy features—it's just a proof-of-concept.

But hey, it works—and that's pretty cool, right? 😅

Building Pomposer has been a fantastic challenge filled with both frustrating and satisfying moments. It's not just another Composer wrapper—it's a completely new take on package management inspired by pnpm. And yes, it's rough, but that's the beauty of open source.

If this excites you and you'd like to see Pomposer evolve, contribute, or share ideas, please join us on GitHub. I can't wait to hear your thoughts and ideas!

How I Accidentally Found Myself Rewriting Laravel (Just to Fix Laravel Modules 😅)

HichemTech — Mon, 10 Mar 2025 15:15:09 +0000

Alright, buckle up folks, because this is the tragic tale of how I thought I was fixing Laravel Modules… only to realize I'd have to rewrite Laravel itself. 🙃

Did I succeed? Nope.

Did I at least break something? Oh, absolutely.

Did I still release a package out of it? You bet. 😎

The Beginning: A New Project 🌟

So here I am, about to start a new project at my company—kind of a big one. And since I’m the most experienced with Laravel (not the boss dev lol, just the Laravel wizard 🧙‍♂️), I had the honor of setting up the project structure.

Now, you might ask, "Why Laravel if the team isn't fully experienced?" Well, actually, they know it—but let's say I'm a bit ahead of them. Plus, honestly, Laravel is just amazing for quick, flexible, easy development. (If you're still thinking, "eeeh PHP nvm," no—get your ass on the computer, and run:

composer create-project laravel/laravel

Try it. Try ittttt. You'll thank me later. 😏

Anyway, back to the story. So I start preparing our setup and, of course, Laravel Modules comes to mind. Perfect for modular architecture, right?

Only... I hadn’t used it in a while. And I totally forgot about the artisan issue. 😭

The Artisan Problem: Oh No, Here We Go Again

First things first: I open my console and run:

laravelfs new alpha

(Alpha is the fake project name; I can’t share the real one, so let’s just pretend it’s some next-gen AI startup or whatever.)

(Oh, and by the way, laravelfs is my own Laravel installer (LaravelFS)! 🚀 I open-sourced it because Laravel 12 removed Breeze, and I was like, *"Oh hell no!" So I made my own installer to fix that and add some cool features. You should check it out! [LaravelFS]) and the story behind :

I picked "none starter," meaning just pure Blade. Why not Inertia? Well, for this scale, Blade feels safer. No big risks, just flexibility.

So, with the project ready, I opened Google and searched "Laravel Modules" (yep, I forgot the vendor name, haha). Nice! The website updated since last time I used it (it was v6, now v12—mostly compatibility changes, but still cool). I quickly typed the usual:

composer require nwidart/laravel-modules
composer dump-autoload

Everything’s great! 🎉

Time to create our first module:

php artisan module:make IOT

Boom, module created! So easy, right? Next step: creating a model called Device. Without thinking, I went:

php artisan make:model Device

❌ ERROR? No. But... wrong path.

Instead of going into Modules/IOT/Models/Device.php, it gets created in App\Models\Device.php.

Wait... hold on, oh damn! 🤦‍♂️ It hit me immediately. This command places the model in \App\Models, not the module I created. How did I forget this?! Right, Artisan doesn’t care about Laravel Modules.*

The Annoyance: Long Commands & No Third-Party Support

The right command was:

php artisan module:make-model IOT Device

So yeah, instead of just using Laravel’s built-in make:model, I now have to specify the module name every single time.

Which is already annoying, but wait, there’s more!

👉 Not all Artisan commands have a "module" version.

👉 Third-party package commands won’t work inside modules.

👉 Spatie packages? Say goodbye to easy module integration.

At this moment, my genius brain (remember that ts-runtime-picker story? Yeah, genius mode activated again 😅) woke up and said, "Hichem, why can't you fix this? No one ever thought of it before, right?"

(spoiler: no, you won’t, Hichem. 😂).

(Hichem is my name btw, no shit sharlok :D).

The Overconfident Attempt: Let’s Hack Artisan! 😎

So here's the deal: the real issue is Artisan commands run only from Laravel's root, So I had this brilliant idea:

"What if I make Artisan work everywhere, dynamically detecting the module?"

💡 Genius, right?! (Totally never been done before, right? Haha. Ha.)

I didn’t even test the theory—I just dove straight in and started coding.

🚀 Introducing… Artisan Everywhere! 🚀 (Yes, another package. Because why not? 😂)

Opened my console, typed composer init and created the pacakge (hichemtab-tech/artisan-everywhere—epic naming skills, I know 😎).

Opened a new PhpStorm window, created a bin folder, and inside it, an artisan.php. At first, I tried to make a batch file (don't ask why, haha), but PHP made more sense for Composer.

What my script did was genius:

It caught any "artisan" command you typed.
Then, it searched upward through your directories, found the root artisan file, and executed commands from anywhere inside the project—no more annoying cd ../../../... Genius, right?

Here’s the script I wrote:

#!/usr/bin/env php
<?php

/**
 * Global Artisan Wrapper - Artisan Everywhere
 *
 * This script searches upward from the current working directory
 * for a local "artisan" file. When found, it delegates all command-line
 * arguments to that artisan file.
 */

// Get the current working directory.
$cwd = getcwd();
$foundArtisan = false;
$artisanPath = '';

// Traverse up the directory hierarchy looking for a local artisan file.
while (true) {
    $possibleArtisan = $cwd . DIRECTORY_SEPARATOR . 'artisan';
    if (file_exists($possibleArtisan) && is_file($possibleArtisan)) {
        $foundArtisan = true;
        $artisanPath = $possibleArtisan;
        break;
    }

    // If we've reached the root directory, stop.
    $parent = dirname($cwd);
    if ($parent === $cwd) {
        break;
    }
    $cwd = $parent;
}

if (!$foundArtisan) {
    fwrite(STDERR, "No local artisan file found in the directory hierarchy.\n");
    exit(1);
}

// Capture command-line arguments (excluding the script name).
$arguments = array_slice($argv, 1);

// Escape each argument to safely pass them to the shell.
$escapedArguments = array_map('escapeshellarg', $arguments);
$argumentsString = implode(' ', $escapedArguments);

// Prepare the command.
// If the artisan file is executable, run it directly; otherwise, use PHP.
if (is_executable($artisanPath)) {
    $command = escapeshellcmd($artisanPath) . ' ' . $argumentsString;
} else {
    $command = 'php ' . escapeshellarg($artisanPath) . ' ' . $argumentsString;
}

// Optionally, you can enable a debug output to see the final command.
// fwrite(STDERR, "Executing command: $command\n");

// Execute the command, relaying its output and exit status.
passthru($command, $returnVar);
exit($returnVar);

🥳 🎉 IT WORKED!

Now I could run Artisan commands from anywhere in my project. No more cd ../../../ nonsense!

The “Oh No” Moment: Laravel’s Internal Paths :))))

Super hyped, I went to my project and ran:

cd Modules/IOT
artisan make:model Device

And...

INFO  Model [C:\xampp\htdocs\alpha\app\Models\Device.php] created successfully.

Wait...

WHAT?!! 😳

Why did it go into app/Models/ instead of Modules/IOT/Models/?!

And then it hit me.

💀 Laravel doesn’t let you change the base path for Artisan commands. 💀

Turns out, when you run make:model, Laravel internally hardcodes the app/ path. It does not dynamically detect modules.

Here’s the problem code inside Illuminate\Console\GeneratorCommand:

protected function getPath($name)
{
    $name = Str::replaceFirst($this->rootNamespace(), '', $name);
    return $this->laravel['path'].'/'.str_replace('\\', '/', $name).'.php';
}

So even though I could now run artisan commands from anywhere…

🥲 Artisan would still default to app/Models/.

The Conclusion: I Gave Up. 😂

I had two choices:

Rewrite a ton of Laravel’s internal command logic.
Accept defeat and keep using php artisan module:make-model.

😂 I took Option 2.

No way Taylor Otwell is accepting a PR that modifies the entire Artisan command structure.

So yeah, I failed. BUT! At least I made Artisan Everywhere, which is still useful. 🎉

And hey, if anyone actually solves this issue, please let me know. I’d love to see it work. But for now… I’ll just keep manually moving files. 😭

That’s it. My failed attempt at rewriting Laravel. Hope you enjoyed my suffering. 😂

Laravel 12 Removed Breeze and Jetstream from the Installer—So I Built LaravelFS 🚀

HichemTech — Fri, 07 Mar 2025 19:27:08 +0000

The Laravel 12 Starter Kit Shift 🤔

Picture this: You open your terminal, run laravel new my-project, and… surprise! 🎭 The usual starter kits you relied on—Breeze and Jetstream—are nowhere to be found. Instead, Laravel 12 now offers a different approach: full project templates hosted on Packagist.

Before Laravel 12, the official installer would set up a blank Laravel project and then install Breeze or Jetstream as a dependency, running breeze:install or jetstream:install. But in Laravel 12, the new starter kits aren’t installed as dependencies anymore—they’re predefined repositories. Now, when you select a starter kit, the installer runs composer create-project, fetching a full Laravel template project instead.

And the kicker? 🥁 When using laravel new, the suggested starter kits are React, Vue, and Livewire. Breeze and Jetstream were completely removed.

Now, don't get me wrong—the new starter kits are awesome! They come pre-configured with ShadCN, modern UI components, and a polished setup that makes building apps even smoother. But at the same time, it sucks that we lost Breeze and Jetstream as official options. Many developers were still using them, and now they had no direct way to install them like before. Naturally, this upset a lot of people. 😡

My Attempt to Fix It (And the Closed PR) 🙃

Like many, I found this change frustrating. So, I thought: Why not just add an option to allow users to provide their own starter templates? That way, people who wanted Breeze, Jetstream, or custom setups could still use them seamlessly.

I opened a PR in the official Laravel installer to introduce a custom starter option, allowing developers to specify their own Packagist-hosted templates. Simple, right? 🤷

Unfortunately, my PR was closed by Taylor. The reason? Laravel already had enough starter kits, and they couldn’t maintain more options.

I was a bit disappointed, to be honest. 😕 But hey, he’s the maintainer. He knows best, and I understood that he had a lot on his plate. 🍽️

Still, I wasn't ready to drop the idea just yet. 💡

Building LaravelFS: A Better Laravel Installer 🏗️

Since Laravel's official installer wasn’t going to support custom starters, I decided to build my own alternative: LaravelFS. 🎉

What LaravelFS Does Differently 🔥

Brings back Breeze and Jetstream: You can now select them just like before.
Adds a custom starter option: You can provide your own Packagist-hosted template.
Introduces a "Templates" feature: Save and reuse your project setup preferences.

How It Works 🛠️

1. Installing LaravelFS:

composer global require hichemtab-tech/laravelfs

2. Creating a new project (with all the missing options restored!):

laravelfs new my-project

You'll be prompted to choose your starter kit, database, test library (Pest or PHPUnit), and additional options like SSR, TypeScript, and dark mode. 🌙

-using The official Laravel installer :

using My installer:

3. Saving a setup as a template:

laravelfs template:new

This runs the same prompts as laravelfs new, but instead of creating a project, it saves your selections as a reusable template. 📝

4. Using a saved template:

laravelfs use my-template

No more repeating the same prompts every time—just use your template and get started instantly! 🚀

A Curious Coincidence… 🤨

Now here’s where things get interesting.

Just a few days after my PR was closed and I released LaravelFS, another contributor opened a new PR with almost the exact same idea: allowing custom starter kits in the Laravel installer.

This time, however, the PR was accepted. Taylor even tweeted excitedly about it. 😃

Now, I’m not saying anything… but it does make me wonder: What was different? Same purpose, same need—but a different outcome. 🤷‍♂️

Conclusion: LaravelFS and Community-Driven Solutions 💡

At the end of the day, LaravelFS exists because developers wanted more control over how they set up their projects. 💪

I don’t hold any hard feelings—maintaining an ecosystem like Laravel isn't easy, and tough decisions have to be made. But this experience was a great reminder that if something gets rejected, that doesn’t mean it’s a bad idea. Sometimes, you just have to build it yourself. 🏗️

LaravelFS is open-source, and I’d love for more people to try it out and contribute! What do you think? Have you felt the impact of Laravel 12’s starter kit changes? Let’s talk about it! 🎤🔥

The Day I Truly Realized I Was a Junior Developer 🤡

HichemTech — Mon, 10 Feb 2025 11:43:38 +0000

Disclaimer: This story is focused on the storytelling aspect of my experience. For the sake of flow and engagement, I’ve skipped detailed code explanations and some technical nuances. The goal here is to share the journey, not to provide a deep technical breakdown.

Introduction: A Lesson in Humility and TypeScript Wizardry

Every developer has that moment—the one where they think they've mastered something, only to be completely humbled by a colleague. This is the story of my moment. It started with a simple goal: improving routing in a React project. It ended with me questioning my entire existence as a developer. 😅

What follows is a journey filled with excitement, frustration, moments of pure dopamine-fueled breakthroughs, and ultimately, an eye-opening realization about experience, skill, and what it really means to be a senior dev. Buckle up. 🚀

The Setup 🎬

It was another day of development, another day of feeling like a pro. I was working on a React project, using createBrowserRouter to handle the routing in Router.tsx. Notice the .tsx extension? Yeah, that’s because createBrowserRouter requires actual JSX components inside element. Let me show you an example of what the router looked like:

export const router = createBrowserRouter([
    {
        path: "/",
        element: <AppLayout/>,
        children: [
            {
                path: "",
                element: <ProtectedRoute><DashboardLayout/></ProtectedRoute>,
                children: [
                    {
                        index: true,
                        path: "projects",
                        element: <OnlyAdmin fallback="/all-projects"><Projects/></OnlyAdmin>,
                    },
                    {
                        path: "projects/:projectId",
                        element: <OnlyAdmin><ProjectGuard/></OnlyAdmin>,
                        children: [
                            {
                                path: "groups",
                                element: <ProjectGroups/>
                            },
                            {
                                id: "project-stats",
                                path: "groups/:groupId",
                                element: <GroupGuard/>,
                                children: [
                                    {
                                        path: "stats",
                                        element: <GroupStats/>
                                    },
                                    {
                                        path: "consents",
                                        element: <Consents/>
                                    }
                                ]
                            },
                            {
                                path: "stats",
                                element: <ProjectStats/>
                            }
                        ]
                    },
                    fallbackRoute("/projects")
                ]
            }
        ]
    },
    {
        path: "*",
        element: <NoMatch/>,
    }
], {
    future: {
        v7_startTransition: true,
    }
});

I loved using createBrowserRouter. It was clean, it allowed nested routes, and I highly recommend it if you’re working with React Router. But then the problem hit.

The Problem 🤯

Across the project, we were using the <Link> component to navigate. Pretty standard, right? Something like:

<Link to="/projects/123/groups/456">Go to Group</Link>

Now, here’s where the chaos began. The client requested a change in the routing structure. Just some small tweaks to paths, nothing major… right? WRONG.

Because now, every single manually written URL in the project had to be updated. 🥲

I was staring at the codebase, thinking: Okay, this is bad. This is really bad.

There had to be a better way—a way to validate links across the app without relying on hardcoded strings, a way to autocomplete routes when writing them, a way to ensure consistency.

My brainstorming mode activated.

🔍 How could I make the routes smarter?

💡 Could TypeScript help enforce route validation?

🤔 How do I make WebStorm autocomplete route names for me?

Then, the stupidest but funniest idea hit me: Should I just make a JetBrains plugin for this? 😂

For a solid five minutes, I was seriously considering writing an entire JetBrains plugin just to solve my routing issue. But then, I shook my head. Hichem, stop. The company is not paying you to build useless plugins.

The "Brilliant" Plan 🚀

Instead, I thought: let’s use TypeScript.

If I could somehow convert route paths into TypeScript-enforced IDs, I could:

✔ Validate links.
✔ Enable autocomplete.
✔ Ensure routes are always correct, no more broken links.

I modified the router to include unique IDs for each route:

const routeObjects: RouteObject[] = [
    {
        path: "/",
        element: <AppLayout/>,
        id: "root",
        children: [
            {
                path: "projects",
                element: <OnlyAdmin><Projects/></OnlyAdmin>,
                id: "admin-projects-list"
            }
        ]
    }
];

I was feeling like a genius. But TypeScript wasn’t cooperating.

I needed TypeScript to dynamically recognize these IDs as valid values. I tried using typeof routesObject, but nope, it didn’t work. After hours of searching the TypeScript docs (not great docs, by the way), tons of Stack Overflow pages, and even brainstorming with ChatGPT, I was getting nowhere.

That’s when the new idea hit: What if I just generate a TypeScript type file dynamically?

Boom. New plan:

Extract all routes into an object.
Generate a TypeScript type file dynamically.
Run a script whenever routes change.

I wrote a script:

npm run generate-router-types

Which would output:

export type AppRoute = 'admin-projects-list' | 'home';

💥 Mission accomplished!

I pushed the PR, took a coffee break, and came back expecting a quick approval.

The "Joe" Moment 😐

Then I saw Joe’s comment. Let’s call him Joe (not his real name, but let’s roll with it).

"I have a better to do this, using only typescript"

My soul left my body. 💀

Bro, do you think I didn’t try that first?!

Then he messaged me directly:

"As-tu 15min pour discuter ta PR ?"

Great. A meeting. With Joe.

Joe was new at the company, but he had a crazy resume—Rust, Go, Node, DevOps, everything. But he also had that energy—the kind of dev who always has a counterpoint to everything.

Still, I joined the call with a whatever attitude. Let’s hear this genius out.

The Humiliation 🤡

Joe shared his screen.

He started explaining.

I saw his code.

And in that moment, I realized… I am, in fact, a junior. 😂

His solution? Pure TypeScript magic.

No build scripts.
No external tools.
No route extraction function.
Just a few lines of TypeScript.

type MergePath<T extends string | undefined, P extends string> =
    T extends ""
    ? P
    : P extends "/"|""
    ? `${P}${T}`
    : `${P}/${T}`;

type ExtractRouteType<T extends RouteObject, P extends string> =
    T extends { path: string } ?
    { route: P, paramsKeys: ExtractPathParams<P> }
    : never;
type ExtractRoute<T extends RouteObject, P extends string> = (T extends { id: string, path: string } ? { [K in T["id"]]: ExtractRouteType<T, P> } : {}) & ExtractRoutes<T["children"], P>;
type ExtractRoutes<T extends RouteObject[] | undefined, P extends string = ""> = T extends [infer R extends RouteObject, ...infer S extends RouteObject[]] ? ExtractRoute<R, MergePath<R["path"], P>> & ExtractRoutes<S, P> : {};
export type RouteById = ExtractRoutes<typeof routeObjects> extends infer U ? { [K in keyof U]: U[K] } : never;

😭😭😭

I had spent hours on a solution that wasn’t even needed.

Joe laughed and said, "Yeah, TypeScript is really powerful when you know how to use it."

Yeah, I got schooled.

The Redemption Arc 🦸‍♂️

But instead of sulking, I fought back. I took Joe’s TypeScript wizardry and improved on it.

I thought: If he can dynamically extract routes, why can't I also dynamically validate parameters?

I wanted TypeScript to enforce route parameters, meaning:

✔ If a route requires :projectId, I should be forced to pass { projectId: string } as params.

✔ If I forgot a param, TypeScript should throw an error.

✔ If I added extra params that weren’t needed, TypeScript should complain.

✔ And of course, autocomplete should still work flawlessly.

I went back to my battle station. 💻☕

I introduced ExtractPathParams, a TypeScript utility to extract only the required parameters from route paths:

type ExtractPathParams<Path extends string> =
    Path extends `${string}:${infer Param}/${infer Rest}`
    ? [Param, ...ExtractPathParams<`/${Rest}`>]
    : Path extends `${string}:${infer Param}`
    ? [Param]
    : [];

Then, I rewrote buildRoute so that it refused to compile if required parameters weren’t passed:

export function buildRoute<RouteId extends keyof RouteById>(
    routeId: RouteId,
    ...params: ParamsArg<RouteId> extends undefined ? [] : [ParamsArg<RouteId>]
): string {
    if (!routes[routeId]) {
        throw new Error(`Route ${routeId} not found`);
    }
    let route = routes[routeId].route as string;
    let params_ = params.length > 0 ? params[0] : {};
    for (const [key, value] of Object.entries(params_)) {
        route = route.replace(`:${key}`, value as string);
    }
    if (route.includes(':')) {
        throw new Error(`Route ${routeId} contains an unresolved parameter`);
    }
    return route;
}

Boom. Now TypeScript would scream at me if I passed the wrong params! 🎯

I also refactored AppLink to integrate this new validation:

const AppLink = <RouteId extends keyof RouteById>({
    routeId,
    ...props
}: RouteBuilderProps<RouteId> & Omit<LinkProps, "to"> & React.RefAttributes<HTMLAnchorElement>) => {
    return <Link to={buildRoute(routeId, props.params)} {...props}/>;
};
export default AppLink;

I ran the tests. Everything worked.

I opened another PR. This time, Joe actually liked it.

"Nice, I like this. Makes sure routes are truly type-safe. Good job."

😭 Sweet validation.

Now, instead of writing:

<Link to="/projects/123/groups/456">View Group</Link>

We could write:

<AppLink routeId="admin-project-group-consents" params={{ projectId: "123", groupId: "456" }}>
    View Group
</AppLink>

✔ No more incorrect URLs.

✔ TypeScript-enforced validation.

✔ Autocomplete for route names & parameters.

✔ Less headache when changing paths in the future.

And just like that, the routing system was finally bulletproof. 🔥

The Lesson 🎓

That day, I learned: experience actually matters.

I could’ve held a grudge. I could’ve been bitter. But instead, I learned, improved, and built upon the knowledge.

The truth is, experience isn’t just about time spent coding. It’s about how deeply you challenge yourself, how far you push your skills, and how much you truly understand your tools.

That PR was a huge lesson for me. It wasn’t just about routing, or TypeScript, or Joe being a TypeScript wizard. It was about growth.

So if you ever find yourself humbled by a better solution, don’t resist it. Study it, build upon it, and make it your own.

That’s what makes a truly great developer. 😎

The End.

Tailwind Without Components? You’re Doing It Wrong 🚀

HichemTech — Sat, 08 Feb 2025 11:12:13 +0000

💡 Tailwind is everywhere, but are we using it the right way?

A lot of us have heard about Tailwind by now and are using it in every project. It’s like a trend—when something becomes popular, we all jump on it, making it a default choice for every new project.

Maybe in your estimation meetings with your boss, you want to impress project managers. Or during story-point discussions, you confidently suggest Tailwind.

Especially when your team starts working on an old project with legacy code, you might think, Boom, I'll tell them to use Tailwind! It's fast, it's modern, and hey, we don’t even need to write CSS files anymore, just use predefined classes and get a nice style!

But… is it really that simple? 🤔

Wait a minute. Ever noticed that Tailwind is mostly introduced alongside React, Angular, or Vue? That’s no coincidence.

Ever wondered why? It’s because these frameworks use a component-based architecture. 🏗️

1. Why Tailwind Works Best with Components 🛠️

Let’s break it down. Say you have a button that’s used throughout your project. In a component-based framework, you would create a reusable Button component and use it everywhere. Simple, right? Now let’s say your boss suddenly tells you, “Hey, remove the rounded effect from all buttons. We have a client demo in 5 minutes.” 😨

No problem! You go to your Button component, remove the rounded class, push the change, get a quick review, merge, and deploy. Maybe the entire process takes 2 minutes, easy! ✅

But now, imagine a different scenario...

2. The Nightmare: Using Tailwind in Legacy HTML/JQuery Projects 😵‍💫

Let’s say you're working on an old PHP project with no structure, drowning in legacy code. Maybe it's still using Bootstrap 3 (ouch). This is the kind of project where if you open it in PHPStorm, JetBrains might call you personally, saying their IDE is down because you've hit the error/warning inspection limit. 😂

Now, in this exciting scenario, you suggest: “Let’s use Tailwind!” You bravely convince the team, everything works fine, and you even manage to remove all CSS files while maintaining the theme. Amazing, right? 🎉

Then your boss hits you with the same request: “Remove the rounded effect from all buttons. Client demo in 5 minutes.”

And that’s when you realize…

🔴 Step 1: PANIC.
🔵 Step 2: Hope there’s a single button file. (There isn’t.) 😬
🟡 Step 3: Start manually editing every button. (Cry internally.) 😭
🟢 Step 4: Search Everywhere in JetBrains. (Why are there so many results?!) 🤯
🟣 Step 5: Discover some buttons are dynamically created in jQuery. (Great.) ⏳
🔴 Step 6: Accept your fate. The demo will happen with rounded buttons. 😵

At this point, you realize: There is NO way you can do this in 5 minutes. Heck, even 8 hours might not be enough! 😵

And that was just removing one simple rounded class. Of course, it's not like the whole demo is ruined because of a rounded button—this is just an example. Now, imagine something actually important, like having to change an entire card layout from grid to flex, or replacing all spacing values across the project to match new design guidelines. Suddenly, you’re digging through countless files, manually updating class names, and hoping you didn’t miss one. Yeah... Yikes. 🫠

3. The Takeaway: Tailwind is for Components 🎯

So now you get it, right? Tailwind is meant for projects that use components. If you’re working in a framework like React, Vue, or Svelte, Tailwind is a dream because styles are encapsulated within components, making updates easy and centralized. ✨

But if you’re dealing with a legacy codebase full of plain HTML and jQuery, using Tailwind can become a maintenance nightmare. In such cases, traditional CSS (or even a framework like Bootstrap) might be a better choice. 👀

Before using Tailwind, ask yourself: “Do I have a component-based architecture?” If not, you might just be doing it wrong. 😉

Lazy Devs, Rejoice! Automate Updates with Dependabot (and My Secret Sauce) 🍹📱

HichemTech — Mon, 30 Dec 2024 23:56:49 +0000

Hey there, busy devs! Are you tired of endlessly scrolling through dependency update emails, manually checking for package updates, or even (gasp) opening your IDE for minor tweaks? 😩 Well, fret no more because Dependabot is here to save the day (and your sanity)! 🚀

Let’s dive into why you should start using Dependabot right now, how it works its magic, and how my PackBumpPR action complements it perfectly for packages with package.json. Ready? Let’s go! 🛠️✨

Why Dependabot is a Game-Changer 🦾

Imagine this: you’re sipping your favorite drink 🍹, scrolling through your phone, and your app’s dependencies are magically kept up-to-date. Sounds like a dream, right? Well, Dependabot makes it reality. Here’s why:

Stay Secure: Outdated dependencies can leave your project vulnerable. Dependabot automates updates, ensuring your project stays secure with the latest patches. 🔒
Effortless Updates: It regularly checks your dependencies and opens pull requests for any updates. You just review, test, and merge. Easy peasy! 🛡️
Saves Time: Forget manually combing through version lists or changelogs. Dependabot handles it for you while you focus on the fun stuff. 🎉
Run Tests Automatically: PRs from Dependabot can trigger your CI/CD pipelines, so you know if the update breaks anything before merging. 👌

In short, it’s your invisible coding assistant, keeping your project lean, mean, and up-to-date. 🤖

How Dependabot Works 🛠️

Automated Dependency Checks:
Dependabot scans your package.json, composer.json, or other dependency files for updates.
Pull Request Creation:
Whenever there’s a new version available, it creates a pull request, including details about the update.
Your Workflow:
- Review the PR.
- Optionally run tests to ensure compatibility.
- Merge it with confidence.

Dependabot even handles semver ranges and will never break your project by jumping across major versions (unless you want it to). How cool is that? 😎

Getting Started with Dependabot 🚀

It’s ridiculously easy to set up. Here’s how:

Add Dependabot to Your Repo:
- Create a .github/dependabot.yml file.
- Add configuration like this:

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"

Push the File:
Dependabot will start checking your dependencies based on the schedule you set.
Review and Merge PRs:
Dependabot will create pull requests for any updates it finds. Review, test, and merge them.

And that’s it! Your project is now in safe, automated hands. 🧙‍♂️✨

The Perfect Partner: PackBumpPR 🛠️📦

Let’s say Dependabot has done its job. You’ve merged a bunch of PRs, and your dependencies are sparkling clean. Now what? If your project uses package.json, you likely need to bump your version number to reflect these changes. 📈

This is where PackBumpPR comes in:

Version Management Made Easy: It automatically updates your package.json and package-lock.json versions.
Pull Request Creation: Creates a branch and a PR for the new version bump.
Dispatchable Workflow: Trigger it manually from GitHub, no IDE required. Update your package from your phone while waiting in line for coffee! ☕

How to Use PackBumpPR 🚀

Add It to Your Workflow: Use the following snippet in your workflow file:

name: Dispatchable Version Bump

on:
  workflow_dispatch:
    inputs:
      version_increment:
        description: "Version increment type (patch, minor, major, or custom)"
        required: true
        default: "patch"
      custom_version:
        description: "Custom version (only if version_increment is custom)"
        required: false

jobs:
  bump-version:
    runs-on: ubuntu-latest

    steps:
      - name: Use PackBumpPR
        uses: your-username/PackBumpPR@v1
        with:
          version_increment: ${{ github.event.inputs.version_increment }}
          custom_version: ${{ github.event.inputs.custom_version }}
          github_token: ${{ secrets.GITHUB_TOKEN }}
          main_branche: "main"

Trigger the Workflow:
Go to the Actions tab in your repo, select the workflow, and click Run workflow. Choose your version increment type (patch, minor, major, or custom).
Review the PR:
PackBumpPR will create a PR for the version bump. Review it, and merge. Done!

Why Combine Dependabot + PackBumpPR? 🤝

Together, Dependabot and PackBumpPR make an unbeatable team:

Dependabot keeps your dependencies fresh and secure. 🌱
PackBumpPR handles version management without breaking a sweat. 💪
You stay productive, even when you’re away from your desk. 📱💻

So, what are you waiting for? Automate your workflow today and say goodbye to tedious updates. Your future self will thank you. 🙌

Lazy devs, rejoice! Automation isn’t just a luxury—it’s the smarter way to work. 🌟

Laravel's 2024: Progress at Lightning Speed, But Are We Biting Off More Than We Can Chew?

HichemTech — Sun, 29 Dec 2024 13:32:43 +0000

🎉 “What a year for Laravel!” If there’s one framework that’s continuously redefining web development, it’s Laravel. 2024 has been no exception—if anything, it’s been extraordinary. From groundbreaking releases to exciting new tools, the Laravel team, led by Taylor Otwell, has been unstoppable. 🚀

But as the saying goes, “With great power comes great responsibility.” With so much rapid progress, I can’t help but wonder: Are we biting off more than we can chew? 🤔

Achievements Galore: What Laravel Delivered in 2024

First, let’s acknowledge the remarkable progress this year. Here’s a quick rundown of Laravel’s 2024 highlights:

Laravel 11: A revolutionary update with cutting-edge features and concepts. 🎊
Inertia v2: A significant upgrade to the frontend scaffolding tool we’ve all come to love. 🖥️
Laravel Cloud: A cloud platform now in early access, offering exciting possibilities for hosting and deployment. ☁️
Laravel Nightwatch: A smart, professional monitoring tool set to outshine Telescope. 👀 (you can take a look at this tool's details here)
Starter Kit Overhaul: The team has begun transitioning to template repositories for different app types, a bold move to simplify and specialize starter kits. 🛠️

It’s no wonder the Laravel community is buzzing with excitement. These developments represent bold steps forward, keeping Laravel ahead of the curve in an ever-evolving ecosystem. ❤️

But Are We Moving Too Fast?

While the rapid innovation is exciting, it’s hard to ignore some growing pains. From unresolved bugs to overlooked community contributions, the speed of development may be creating cracks in the foundation. 😟

Here are some examples that highlight the tension between progress and stability:

1. Inertia v2: Stability and Merging Bugs

The release of Inertia v2 has been a mixed bag for developers. While the new features are impressive, some bugs have left us scratching our heads.

Take issue #2122:

The Problem: On mobile devices, the browser’s "Back" button doesn’t behave as expected when prefetching is enabled.
Community Feedback:
- “Looks like the fix from the 1.3 beta did not make it into the 2.x beta yet.”
- “Why was v2 marked as stable without bug fixes from version 1.3?”

This kind of instability raises questions about whether the release process is leaving some edge cases behind. 🤷‍♂️

Another example is issue #2068:

The Problem: The Inertia::merge() feature doesn’t handle nested arrays properly. For instance, in a pagination object:

  {
      "data": [/* items */],
      "meta": { /* metadata */ },
      "links": { /* links */ }
  }

Instead of appending new items to the data array, the entire array is replaced—leading to data loss. 😨

Proposed Fix:

Two community-driven PRs (#2069 and #679) introduced a deepMerge feature to handle such cases. This would allow incremental updates to nested structures while preserving the consistency of unrelated fields.
The Problem with Docs:

To make matters worse, the official documentation suggests that merging already works as expected, creating confusion for developers relying on outdated guidance.

Despite these contributions from the community, the PRs remain unreviewed, leaving developers stuck. 🙃

2. Laravel Cloud: Bugs in Beta

Laravel Cloud, currently in early access, is an exciting new addition to the Laravel ecosystem. As with any early-stage product, it’s natural for some bugs to surface. The community is eager to see how this platform evolves and reaches its full potential. It’s clear that Laravel Cloud has the promise to simplify hosting and deployment for Laravel applications, and we’re optimistic about its future. ☁️✨

Constructive Feedback: What We Hope For

We’re not here to complain—we’re here to collaborate. Here’s what we believe could make Laravel even better moving forward:

💡 1. Prioritize Community Contributions:

The Laravel community is incredibly talented and eager to help. By reviewing and merging PRs more efficiently, the team could tap into this collective expertise and lighten their own workload.

💡 2. Ensure Stability Before Release:

Labeling something as “stable” sets expectations. Taking extra time to address critical bugs and edge cases would help maintain trust and reliability.

💡 3. Communicate More Openly:

Transparency is key. Whether it’s issue backlogs, priority updates, or timelines, keeping the community in the loop fosters collaboration and enthusiasm.

Conclusion: A Message from the Community

Laravel’s achievements in 2024 have been extraordinary. 🎆 We’re incredibly grateful to Taylor Otwell and his team for their vision, hard work, and commitment to excellence.

But with great progress comes great responsibility. As users and collaborators, we want to ensure the ecosystem remains as strong and reliable as it is innovative. After all:

"We’re not just users; we’re collaborators. Please don’t leave us blocked."

Here’s to another amazing year of Laravel—let’s keep building greatness together! ✨

How I Destroyed Half of My Full Stack Developer Career Before It Even Got Started, Because of Google

HichemTech — Fri, 20 Dec 2024 22:55:41 +0000

It was about five years ago. Back then, I was a developer… well, when I say "developer," I mean just a boy who had just stepped into the world of programming. 😅 I’d been coding for about a year, focusing on building websites and Java Android apps. But I wanted more. I dreamed of creating games—the kind that would light up the Google Play Store. ✨

So, I started learning Unity. I was programming with my friend Younes (shoutout to us! Hichem and Younes 🙌), we were total newbies in the ecosystem, but even thought we created some surprisingly good games: Code Breaking, Keep It Up, Count It, Chess Games, Color Guessing Games, Avoid & Run, and more. Honestly, for two amateurs, our games were solid—worthy of competing alongside Ketchapp and Voodoo titles (at least, that’s what we told ourselves 😂).

We decided to take the leap and buy a Google Play Developer account. With $25 pooled together, we bought the account. What a moment! We could actually publish apps! 😍 Being young and inexperienced, we faced a lot of rejections from Google at first (terms and policy violations and all that blah blah blah 🙄). But eventually, we managed to publish our games.

You can’t imagine the dopamine rush we felt seeing our games live in the Google Play Store. 🥳 I’d tell my friends and family, “Hey! Go to Google Play and search ‘Keep It Up’” (our game name) or “Look up ‘Studio Lab tech’” (the name we chose as a brand LOL). The joy was unreal.

Some of the screenshots when we were building our games

A Quick Detour to Disaster

After about a year, life got busy with studies. We didn’t have time to build new games. One day, while scrolling through Upwork and Fiverr, hunting for tasks to make a little extra cash, I stumbled across an offer: $5 for someone with a Google Play Developer account to publish an app. 🤔

"Wow, that’s me! I have a developer account,” I thought. Quick $5? Why not? 💸

So, I did it. I uploaded the app, fixed a few errors flagged by Google, and got my $5. Nice! I started actively seeking out these publishing gigs. But something puzzled me—why didn’t these developers just buy their own accounts for $25? It seemed illogical. 🤷‍♂️

It wasn’t long before I discovered the answer… the hard way. 😔

The Beginning of the End

After publishing a few apps for $5 each, Google began sending alerts. One after another. Violations. Terms and policies. The worst part? I couldn’t delete the apps I uploaded. I tried archiving them but hesitated. Archiving would mean refunding the $5, right? So, I left them. Big mistake. 😓

Then came the dark day. I woke up, checked my email as usual, and saw the message:

“Hi Developers at Studio Lab Tech, this is a notification that your Google Play Developer account has been terminated.”

Just like that, we were terminated. I immediately called my friend. At first, we weren’t too worried. Surely, there must be a way to restore the account, right? Wrong. 😭 After some research, we found the devastating truth:

You can no longer be a Google Play Developer. Ever. 😱

Even creating a new account wouldn’t work. Google has ways to detect it. Our career in Android development was over. 💔

Growing But Shackled

Fast forward four years, and my friend and I are now seasoned developers. We’ve nailed it in web and app development: Java, React Native, Unity C#, Kotlin, Ionic, Flutter… you name it. But for what? We can build incredible apps, but we can’t publish them. The joy of seeing our creations live on Google Play? Gone. 😢

Google’s decision feels incredibly harsh and unjust. People change. Even criminals get a chance to redeem themselves. But for us, it’s a life sentence. We were young, inexperienced, and ignorant of the rules. We’ve learned so much since then, but the ban remains.

Now, I’m a full stack developer working with React, MongoDB, Laravel, Symfony, Java, and Python. But when it comes to Android apps? I’m locked out. Some of the best apps I’ve built sit idle, unpublished, breaking my heart every time I remember that I can’t share them with the world. 💔

Google, Why?

Google’s policy is understandable from a business perspective. They want to save time and money by eliminating risky accounts. But a lifetime ban? It’s extreme. Why not charge a higher fee for account restoration or allow for probationary periods? Why not give second chances? 😕

I’ve sent multiple appeals over the years, explaining my situation. “I was just a kid,” I wrote. But every time, the answer was the same: “No.”

My career—half of it, at least—is dead. I know I’m not alone. Many developers are in the same situation. We’re not asking for much—just a chance to prove we’ve changed, to redeem ourselves. 🙏

Google, please reconsider.

To anyone reading this: What can we do? Is there any hope? My wish, my dream, is for Google to give second chances. Until then, the apps I build will remain unpublished, and a part of my career will remain unfinished. 😔

Beyond Type Safety: making TypeScript smarter by Building a Runtime Picker

HichemTech — Sat, 14 Dec 2024 00:23:35 +0000

Disclaimer

Hey, before we get started, let me clarify something: while I’ll be talking a lot about my package, ts-runtime-picker, this isn’t a promotional article. I’m just sharing my experience and the journey I took before building it. (But hey, if you're curious, here's the link to the package 😉).

How TypeScript Led Me to A New Idea (And a Package)

Let’s rewind a bit. So, I’ve been working with TypeScript for a while now. I wouldn’t call myself a TypeScript pro, but I’ve built a few big projects and worked with it at my company. You know, the usual—some “hello world” projects, some slightly more complex ones, and of course, a fair share of trips to Google to figure out “what the heck does this error mean?” or “How do I pick fields from an interface again?” (You get the point. 🙃)

One day, I ran into an issue while working with Firebase cloud functions. I was on the createUser endpoint, writing my validation logic, trimming data, and handling the usual CRUD request madness. Everything was moving smoothly until I ran into this piece of code from a previous developer:

firebase.collection("users").add(request.data.user);

...and my inner TypeScript pro was screaming. 🚨

I mean, come on, this was a massive red flag. Right? Inserting unfiltered user data directly like that was risky—what if the request data was missing some validation and we ended up inserting unwanted fields into the database? Not great.

I quickly removed the code, but then, I froze for a second. 🤔 I stared at my screen thinking: "Hold on, if I just assign request.data to the User interface type, wouldn’t TypeScript stop me from doing something like this? Shouldn’t this fix the issue?" (Cue a hopeful glance at my IDE, waiting for the red squiggly lines to appear.)

But wait… 🤦‍♂️ TypeScript is not magic. It's only a compile-time check, right? It doesn’t exist in runtime. TypeScript is a mask for type safety, but it doesn’t actually enforce anything when the code’s running. It doesn’t really stop extra fields from being inserted at runtime.

So, I called up one of my teammates and asked, “Hey bro, if we have an object named alphabets with all the letters in the alphabet, and we create an interface OnlyTwoLetters that only allows the letters 'a' and 'b', what happens when we cast the alphabets object to that interface?”

// Object with all alphabet letters
const alphabets = {
  a: 'Apple',
  b: 'Banana',
  c: 'Cherry',
  d: 'Date',
  e: 'Eggplant',
  f: 'Fig',
  // ... all the way to z
};

// Interface that only allows 'a' and 'b'
interface OnlyTwoLetters {
  a: string;
  b: string;
}

// Casting alphabets to OnlyTwoLetters
const filteredAlphabets = alphabets as OnlyTwoLetters;

console.log(filteredAlphabets);

Without missing a beat, my teammate said, “Haha, well, you’d still get all the alphabet letters because TypeScript can’t really stop that in runtime.”

Damn. I knew it. I was under the effect of hope—hoping that TypeScript could magically prevent me from making mistakes at runtime. 🙄

But then, it hit me: What if TypeScript could enforce this at runtime? What if we could cast an object to a specific interface and have TypeScript automatically strip out any properties that weren’t defined in the interface?

That would solve my problem.

The Birth of `ts-runtime-picker`

So, with this lightbulb moment, I thought: “Why not make this a reality?” If I could cast request.data to the User interface, TypeScript could help me automatically remove any extra properties, making the object safe to insert into Firebase. 🎉

And just like that, the idea for ts-runtime-picker was born. The goal was simple: create a package that would allow TypeScript users to filter out unwanted properties from an object, based on the fields defined in a specific interface.

The best part? It would save me from the manual validation and filtering of fields. Gone were the days of:

const filteredData = {
  name: requestData.name,
  age: requestData.age,
};

firebase.collection("users").add(filteredData);  // More work, less fun.

How It Works: Let TypeScript Do Its Job

With ts-runtime-picker, the whole process is automated. You can cast an object to an interface, and the package will ensure that only the properties defined in the interface are kept. Here's how it works in action:

Before: Manual Validation

interface User {
  name: string;
  age: number;
}

const requestData = { name: 'John', age: 30, address: '123 Street' };

// Manually check and remove unwanted fields:
const filteredData = {
  name: requestData.name,
  age: requestData.age,
};

firebase.collection('users').add(filteredData);  // Not very elegant.

After: With `ts-runtime-picker`

import { createPicker } from "ts-runtime-picker";

interface User {
  name: string;
  age: number;
}

const requestData = { name: 'John', age: 30, address: '123 Street' };

// Automatically filters out non-existent properties:
const picker = createPicker<User>();
const safeData = picker(requestData);

firebase.collection('users').add(safeData);  // Much cleaner!

The best part? This code is safe by default. No need for manual checks or object manipulation. ts-runtime-picker automatically handles it for you by filtering out all fields that don’t exist in the User interface. You can just focus on your core logic without worrying about accidental field insertion. 🙌

The Power of Laziness (and How It Can Lead to Innovation)

So, you might be wondering: "Did this come out of sheer laziness?" And to that, I say: Yes, but also, no. 😅

Sure, the initial spark of the idea came from me being a little lazy—I didn’t want to manually filter fields every time I needed to insert data. But hey, sometimes laziness leads to brilliance! The desire to make things easier can be a driving force for innovation.

In fact, despite the initial “laziness,” I spent 8 hours building the package. Yeah, that’s right. 😆

But that’s how it goes sometimes. "The need gives birth to invention," and this need to avoid tedious repetitive checks led to a new solution that ultimately made my life (and hopefully many others' lives) a lot easier.

So, while I can blame laziness for getting the ball rolling, it was the need to solve the problem that gave rise to ts-runtime-picker. And that’s how sometimes, being stuck or lazy isn’t necessarily a bad thing—it’s the birthplace of something new and useful!

Conclusion

And that’s the story behind the ts-runtime-picker package. A journey from TypeScript frustration to creating a tool that solves a real problem. This package is my way of helping TypeScript users take full advantage of type safety — not just during development but also in runtime.

If you’re tired of manually filtering fields or worried about unwanted data sneaking in, give ts-runtime-picker a shot. It’s one less thing to worry about, and it makes working with TypeScript just a little bit smarter. 😄

Introducing Laravel Nightwatch: A New Age of Monitoring Your Laravel Apps ✨

HichemTech — Wed, 27 Nov 2024 23:37:41 +0000

Hey there, Laravel enthusiasts! 👋 If you thought deploying a Laravel application was as good as it gets, think again—because Laravel Nightwatch is here to take your development journey to a whole new level! Say goodbye to staring into the black box of performance issues and hello to crystal-clear insights 🕶. Taylor Otwell and Jess Archer introduced this exciting new tool at LaraconAU 2024, and it promises to make monitoring your Laravel applications not only informative but also, dare I say… fun! Let's dive in 💌.

🚀 What is Laravel Nightwatch?

Laravel Nightwatch is a hosted, fully managed observability platform designed specifically for Laravel applications. Think of it like the ultimate co-pilot for your Laravel app—always watching, always ready to provide you with the deep insights you need, and 100% tailored for Laravel. No hours of configuration, no generic dashboards, just real actionable metrics that matter to your app. It’s all about leveling up the way we understand and respond to our app's health and performance.

Laravel Nightwatch just works, and it looks amazing. - Taylor Otwell

🛡 Nightwatch vs. The "Others"

Unlike traditional monitoring tools that try to cater to every tech stack (which is often why they’re frustrating to use), Nightwatch is obsessively optimized for Laravel. Here’s why that matters:

☆ Out-of-the-box configuration: You just composer install the Nightwatch agent, ship your Laravel app, and boom—you've got yourself a beautiful dashboard 📊.
☆ Deep Integration: Laravel-specific metrics are displayed in a way that makes sense to Laravel devs. It’s not about reinventing the wheel—it's about putting the right wheels on the right car 🏎.
☆ Easily see what matters: From N+1 query issues ❌ to detailed request timelines ⌚, Nightwatch makes it simple to dig deep without getting lost.

💡 Dive into the Features

Nightwatch isn't just about pretty charts (though, let's admit, the UI is gorgeous 💃). It offers a plethora of practical and insightful features to help you master your app's health:

1. Dashboard Overview 🔹

From the moment you log in, Nightwatch presents you with a clean and effective overview. The top graph lets you see your web requests: successful ones in green and issues popping in red and orange. You can see spikes, track errors, and get a sense of how your app is faring.

2. Performance Insights ⚡

Wondering why that one page in your app is running slower than a sleepy snail? 🐌 No worries, Nightwatch lets you drill down into individual requests. You can check out every lifecycle stage of a request—from middleware to queries—giving you the power to figure out exactly what went wrong.

Nightwatch provides insights like P95 (95th percentile) for requests and jobs, so you can focus on bottlenecks without being distracted by outliers.

3. N+1 Queries? Not on My Watch! 🔎

No Laravel dev loves stumbling across an N+1 query. Nightwatch not only detects these situations for you but also provides all the context so you can squash them before they eat your database alive 🤖. Clicking on an offending query shows its exact origin and the routes that called it, so you’ll be back in the green in no time.

🎉 Full Traceability - From Users to Exceptions

Ever wanted to follow a user's journey through your application and see exactly where they tripped? Now you can 🤷‍♂️. With Nightwatch, each request, each job, and even the exceptions are tied together, allowing you to trace back the root cause of the problems in a few clicks. It’s all about getting the "big picture" view with the ability to zoom in on those tiny little things that make a big difference.

🚪 Real-User Insights & Logging

We all know that apps aren't just about backend performance, but about user experience 👤. Nightwatch lets you filter and track actions by individual users, meaning you can dig into the requests made by Tim, see where he experienced exceptions, and even identify if he’s having a rough day with your app. 😬

Logging is integrated seamlessly into Nightwatch—no more jumping between a million different tools to find that one pesky bug.

💡 Alerts That Care About You 🙌

No one wants to babysit a dashboard 24/7. Nightwatch provides alerts for the things that matter—you can set conditions like "notify me if requests take longer than 500ms for more than 5 minutes." It’s all about meaningful notifications (not spam 📬), so you’ll always know when your app needs your love and care.

🛠 Setup & Availability

The good news? Laravel Nightwatch is coming soon, with early access opening up towards the end of this year, and beta availability in early 2025. And don’t worry—you won’t need Laravel Cloud to use it, though it integrates beautifully if you do 🥳.

Getting started is as easy as:

install nightwatch
Ship your Laravel app ✈
Enjoy the insights 📈

🎉 Wrapping Up

Laravel Nightwatch is set to redefine how we think about app observability. It’s built with the same care and philosophy that we love from Laravel—simplicity, developer happiness, and making tough things easier. It’s not just a monitoring tool; it’s the sidekick your Laravel app deserves.

So whether you’re building for a startup, or a product used by millions… it’s time to keep an eye out for Laravel Nightwatch 🌍⚡.

Get on the waitlist now, and let Nightwatch have your back!