DEV Community: Jhon William

Deploying any app to GitHub Pages

Jhon William — Wed, 21 Aug 2024 20:47:12 +0000

GitHub Pages is a website holder for you & your projects. You can host your code directly from your GitHub repo. This article will help you how to manage your app in the master branch and deploy the code in the gh-pages branch easily.

You can choose any front-end framework like React, Vue, Gatsby, Next, Nuxt, Gridsome, and build the app in the master branch and build the code using the npm run build command and host directly using the gh-pages branch.

The quickest way to put your app to GitHub Pages is by using a package - gh-pages.

'''bash
npm i gh-pages -D

or you can install the package globally
'''bash
npm i gh-pages -g
Add this simple script to your package.json
'''json
{
"scripts": {
"deploy": "npm run build && gh-pages -d dist"
}
}

Note: Assuming the build folder to be dist

When you run npm run deploy all the contents of the build folder will be pushed to your repository’s gh-pages branch.
If you are creating a User page in GitHub
Create a repository with your username like username.github.io, Create a branch called code or you can name the branch anything. Build the app in this branch and when it comes to deploying the app use the gh-pages command to push the build folder contents to the gh-pages branch

Note: In this case, you need to push your build directory to master branch, use the following command
'''json
{
"scripts": {
"deploy": "npm build && gh-pages -d dist -b master",
}
}
After running npm run deploy you should see your website at http://username.github.io

Run gh-pages --help to list all the supported options of the gh-pages package

Useful npm scripts of gh-pages
If your source code of the app is in a private repository, create a public repository named about, the source code will reside in the private repository and the static content generated from the build will go into the public repository
'''json
{
"scripts": {
"deploy": "gridsome build && gh-pages -d dist -b master",
}
}
To include dotfiles while pushing the changes to the branch

'''json
{
"scripts": {
"deploy": "npm run build && gh-pages -d dist -t"
}
}
To change the commit message when publishing the change
'''json
{
"scripts": {
"deploy": "npm run build && gh-pages -d dist -m Build 21082020v1"
}
}

50 Essential Tips for Every Developer

Jhon William — Wed, 21 Aug 2024 04:36:08 +0000

Whether you are starting to program or you are twenty years into your career, there is something here for you. Enjoy!

You are never ready. That's the fun part.
Focus on one thing at a time.
Just start! You'll figure everything out automatically.
Build. Build. Build again.
Sleep is important.
Asking for help is not a sign of weakness.
Watching every tutorial won't make you a developer.
Writing your own code will make you a developer.
You only need the fundamentals.
Always plan your work.
Have other hobbies. If programming is your hobby, explore new fields.
Expect more from yourself than others will.
Take your time and write tests.
Read blog posts. Listen to podcasts. Subscribe to newsletters.
Learn to read the documentation.
Make a lot of mistakes.
Quit looking for perfection. If it works, it works.
If it works, touch it.
Take a break.
Connect with more people.
Pair program if you can.
Teach others what you know.
Look for mentorship. If you can mentor someone, do it.
Read more books. Fiction and Non-fiction.
If you honestly think you are bad, pretend you are a good programmer and never stop pretending.
Do not quit.
If the tools you use feel like magic, start digging in and see under the hood.
If you don't understand, copying is not the best idea.
Watch conference talks on YouTube.
Attend meetups and conferences too if you can.
Always be a team player unless you work as an independent person.
Readability is way more important than shortness.
Learn more what you like than what you think you should.
Find a balance between theory and practice.
Invest in your development setup.
Learn. Keyboard. Shortcuts.
Be consistent.
Try a new language.
Define your payment terms explicitly.
Enjoy your little winnings.
Don't be scared to show off your work.
Learn to comment your code.
Listen to advice but make your own decisions.
Support other developers. Sponsorships and the likes.
Learn from everything and everyone and never miss the opportunity to learn.
You should not be afraid to have simple solutions to simple problems.
Take care of your mental and physical health.
Try explaining concepts in writing and publishing.
At the end of it all, there is family.

next over remix

Jhon William — Wed, 21 Aug 2024 03:01:05 +0000

According to my 2023 goals, my first task of the year was to convert my website to Remix and Tailwind. I completed the Tailwind conversion back in February, and the Remix conversion took me just over a month. Here's how it went.

🍰 conversion process

Converting from Next.js to Remix was pretty straightforward. I started by swapping out the next.config.js for a remix.config.js. Then I had to map the _app.tsx and _document.tsx files to the Remix equivalent root.tsx file.

Next I moved all of my pages into the routes folder and modified the structure slightly. All of the getStaticProps calls had to be converted to Remix loader functions, and I had to use the Remix meta function for SEO information. Then I swapped out the Next component for the Remix one.

Ultimately the pull request was only a four line difference if you don't count the package-lock.json file. Both frameworks were structured in a similar manner, but something about Remix felt simpler.
😖 issues
The project wasn't without issues though. The first problem I noticed was that sometimes page transitions weren't loading data correctly. That's because the loader functions must be exported inline, rather than at the bottom of the file.
export const loader = () => {}
The next issue I hit was a very weird one. Once deployed to Vercel, I was no longer able to read my local markdown files. After some deep searching, I found that referencing process.cwd() does not work the same in Remix as it does in Next.js when hosted on Vercel. The solution was to use dirname to construct paths, so that they can be statically analyzed by the hosting platform.
const postsPath =${dirname}/../content/posts``
Another similar problem I ran into was with gatsby-remark-vscode causing build failures. Internally it looks for some other files in nearby directories, which were not in their expected locations because I had told Remix to bundle all server dependencies. Unfortunately I never found a solution to this problem.

But the last issue I ran into was enough to put a stop to the project. Because Remix is an SSR framework, I was sending API requests to fetch my latest YouTube videos on every page load, which depleted my quota and caused me to get rate limited for the rest of the day.

I investigated using cache headers on the request sent from the server and from the browser, but nothing seemed to have any effect. Instead of go further down the caching rabbit hole with something like Redis, or set up a cron job to pull my latest videos, I decided that it was too much infrastructure for a static site.

🏎️ performance
But regardless, I wanted to see how a fully server rended application performed when compared to my existing Next.js site.

Next.js Remix
Requests 52 27
Transferred 992kb 990kb
Resources 2mb 2mb
Finish 1.2s 1.5s
DOMContentLoaded 500ms 750ms
Load 850ms 1.2s

Despite the fact that Next.js had many more network requests to fetch neighboring pages, it was faster in nearly every way! The loading experience was identical in both applications, with no noticable differences in layout shift or perceived loading time.

🎬 conclusion
Given the issues I ran into, it showed me that Remix isn't the right choice for a static blog. While the simplicity and developer experience is amazing, Remix really shines for authenticated web applications. That's why we're using it at Atlassian for our latest internal tools.

With that being said, I'm going to stick with Next.js for now. I'm still hosting on Vercel, and they go together like peanut butter and jelly. However, I'm still debating on how far I push into the Next.js ecosystem. I recently made an effort to remove the component from my codebase, as it locked me into using Next.js. But their new @next/font module is very enticing...

At the end of the day, I should stop rewriting my website and start finishing all of the blog ideas I have!

🧪 vscode test current file task

Jhon William — Wed, 21 Aug 2024 02:22:55 +0000

While setting up a new project at Atlassian, I decided to dive into some vscodeworkspace settings to see how I could improve the developer experience. I found the task system to be pretty interesting and extensible, so I created a custom task to run tests against the currently open file.

Custom task definitions are placed in .vscode/tasks.json. Most of the fields are straightforward, but the command property has some interesting bits. There are all sorts of variables you can use to get information about the current file and directory you're in. You can also do things like run a task when a workspace is opened with the runOn property. Here's what my task definition looked like.

{ "version": "2.0.0", "tasks": [ { "label": "test current file", "type": "shell", "command": "npm run test ${fileBasenameNoExtension}.test${fileExtname}", "group": "test", "presentation": { "clear": true, "close": false, "panel": "dedicated" } } ] }
To run this task, open up the command palette by pressingCmd+P. Then select Tasks: Run Tasks to view a list of custom tasks. Finally, choose the test current file task from the list. If you ask me, this is a much better workflow than executing npm run test and then entering in the exact file path you're looking for.