DEV Community: Luigi Zaccagnini

First Week of Telescope

Luigi Zaccagnini — Sat, 22 Jan 2022 05:03:04 +0000

This week has been a tough week with the issues I have been trying to solve. This week I was focusing how to start integrating React Native into Telescope through this discussion. A lot of good things came from the discussion like:

Keeping a Monorepo.
Deciding on the Expo CLI.
An idea on a UI library to start with.

After figuring out how to move forward with the React Native, I wanted to fix an issue for the Release but I never got to make it. I was working on CSP error in Dashboard with inline (“script-src” #2511). I was able to get CSP examples from Amasia. After reading through the website I tried the two methods of fixing the issue, hashing the function and putting it in the script-src or using nonces on the scripts causing the errors. I took me awhile to hack away with these methods as I thought the material-UI library was causing the scripting error but, I figured out that it was not. After trying to use the debugger to figure out the problem I had to take a break and step away from the computer for a little bit. I am hoping to look back at it with a pair of fresh eyes this week and finally close these issues. After I finish this issue and another issue assigned to me, I want to officially kick off React Native development.

Getting Telescope's React Native App

Luigi Zaccagnini — Sat, 15 Jan 2022 00:18:43 +0000

Hello again! It's me, Luigi again and today I am going to talk about the vision of Telescope getting a React Native App. This is a very big subject so I am going to go over as much as I can during this blog post. Things I am going to discuss are:

What is React Native?
React vs React Native?
What CLI we should use for our development?
Possible Telescope Goals
How can you get started to help?

What is React Native?

React Native?

React Native is a framework that allows programmers to write JavaScript code to build mobile applications. Some of the devices that React Native can build for currently is IOS, Android and Windows(Still new and buggy).

React vs React Native

React is a library in JavaScript that is used for building front-end web applications. React Native uses the React library to build the front-end for the application.

What React Native CLI Should we use for our Development?

Expo CLI vs React Native CLI

When using React Native and starting a project you have the choice between two CLIs(Command Line Interfaces). You can choose between React Native's or Expo's. Both are awesome tools to build with but, each have their pros and cons.

Expo CLI

Pros:

Fast development setup
Quickest way to start development with React Native
Live reload in Development
Library linking
Can test app on apple/android devices (Expo builds apps)
Can eject/convert back into a React Native CLI

Cons:

Builds are done by Expo
Native modules are not supported
Expo apps are bigger because all libraries are included

React Native CLI

Pros:

Builds are done locally
Native modules are supported
You have more control over app size

Cons:

Slow development setup
No live reload in Development
No library linking (things need to be linked with react-native link)
Can't turn into an expo app

Why I Recommend Expo as our Starting Point?

As someone who has worked with both, I think we should start development with Expo because it is easier/faster to setup for development, easier to develop in and can always be converted back into React Native CLI. This will encourage open source developers to learn and contribute because of how much easier it is to get involved with the project. Although React Native CLI provides native module support and control of the app size, I do not believe that those things are worth the frustration of working with the React Native CLI. If there are more pros or cons you know, please leave a comment in the description.

Telescope

Starting Point

I think the first goal we should have for functionality of the app is to have blog posts with basic user information display correctly. Although it sounds easy we are designing/developing/testing a new app that requires a lot of configuration, learning and fixing. A more detailed goal list would be:

Splash Screen
App Icon
Published on app store
Get time line of blogs to display with user information correctly
Basic navigation setup

Once we hit that goal we can add user authentication and eventually slowly layer more features onto the app and create better work flows with the power of Expo! If you have any ideas to add for goals please comment below!

How can you get started to help?

Well now you're wondering "How can I get involved?". Well to start, you should review documentation and practice using Expo so when we start development you're ready! The Expo Documentation is an amazing source for learning how to get started with react native! They teach you everything from installing react native to learning work flows. Once you feel a little comfortable you should make a small prototype! I feel like when I learn a new framework, I try to create a small project to help me understand how to practically use the tool. Some ideas are a TODO app, Book app that displays book information, News app and really anything that inspires you!

Progress on Terminus

Luigi Zaccagnini — Sat, 11 Dec 2021 04:52:36 +0000

So far the problem with Terminus has stayed the same. I am currently trying to find a better way to communicate with the people of the community for my pull request. This repository doesn't get updated quite often so I am hoping that someone can review the pull request soon so I can spend more time improving. Everything was left off with tests working and the headers being passed correctly.

Conclusion

Although this was a short blog post about the status of the pull request, I wanted to go into detail about the entire experience of contributing. When I first picked the issue, I thought I would be working with the Telescope project. I decided to work with this code base because I was very comfortable and understood the project. I also found during this semester that working with newer projects took me a lot longer to learn and setup. Once I found out that I would have to work within Terminus, I was a little intimidated. I was worried it would take time to learn the code and understand how to work with it to get exactly what I needed. Eventually after moving on from being intimidated, I spent each night slowly examining the code and coming up with solutions to the problem. After that process I created the pull request. Working on this problem and the many problems this semester was a journey and I hope to work on more open source projects in the future in OSD700.

Working on GoDaddy Terminus

Luigi Zaccagnini — Fri, 10 Dec 2021 02:36:09 +0000

Hello! Welcome to another blog post. Today I will be discussing my progress on my Telescope issue and how I got to Terminus.

Trying to Solve the Problem

To start, I thought I could solve Telescopes Issue by fixing some code on Telescope or Satellite in order for the CORS errors to stop. I soon learned that the main problem wasn't fixable from our code bases and had to be fixed from Terminus.

Working on Terminus

Once I moved to Terminus's issue I began to start learning the code and ways I can solve the CORS issue. I discussed ways inside the issue thread about how I can solve the CORS issue and how I could add middleware. The proposed ideas were all hypothetical solutions so I didn't know if they could work until I started working in the code.

Problems Encountered

While trying to solve this problem I tried to add middleware with compose-middleware. While trying to implement it I had troubles with integrating the middleware with the server. Since the middleware wasn't working I attempted to allow users to write headers instead.

Coding in the Terminus Project

Once I got comfortable and understood the code of the project I wanted to create a mock project to help.

const http = require("http");
const express = require("express");
const terminus = require("../terminus/index.js");
const app = express();

app.get("/", (req, res) => {
  res.send("ok");
});

const server = http.createServer(app);

function healthCheck({ state }) {
  // `state.isShuttingDown` (boolean) shows whether the server is shutting down or not
  return Promise
    .resolve
    // optionally include a resolve value to be included as
    // info in the health check response
    ();
}

const options = {
  healthChecks: {
    "/healthcheck": healthCheck,
    verbatim: true,
    __unsafeExposeStackTraces: true,
  },
  headers: {
    "Access-Control-Allow-Origin": "*",
    "Access-Control-Allow-Methods": "OPTIONS, POST, GET",
  },
};

terminus.createTerminus(server, options);

server.listen(3000);

This test project would help me test if I could pass headers to my local version of Terminus, and if I could fix any CORS related issues with the health check.

Within Terminus I wrote an extra parameter to allow users to send over their header options:

 decorateWithSignalHandler(server, state, {
    signals,
    onSignal,
    beforeShutdown,
    onShutdown,
    timeout,
    logger
  }, options.headers)

By passing the header parameter through the decorateWithSignalHandler I am now able to give the sendSuccess and sendFailure functions the headers information needed so I could write my CORS headers.

Conclusion

So far everything is working and the next steps are to get the pull request accepted and to figure out a way to include middleware into the project.

Planning for Contributing to Telescope

Luigi Zaccagnini — Sat, 04 Dec 2021 01:33:09 +0000

Hello! Welcome to another blog post about contributing to open source. This blog post I am going to discuss the issue I picked to solve and how I am planning to solve it.

Issue at Hand

The issue I decided to choose for this was issue 2444. This issue is about adding CORS to the health checks in Telescope. CORS(cross-origin resource sharing) allows for restricted resources (Stylesheets, scripts, etc.) from one domain to be accessed from another domain. For this issue, when Satellite another Seneca open source project tries to communicate with telescope it causing the CORS issue.

Action Plan

Since this issue requires me to add CORS to satellites health checks, I will have to implement CORS into the src/satellite.js. Here is a rough idea:

const { createTerminus } = require('@godaddy/terminus');

const { createApp, createRouter } = require('./app');
const redis = require('./redis');
const elastic = require('./elastic');
const logger = require('./logger');
const cors = require('cors');

function createServer(app, credentials) {
  // If we're given key/cert credentials, use HTTPS,otherwiseHTTP 

  app.use(cors()); 

  if (credentials) {
    return require('https').createServer(credentials, app);
  }
  return require('http').createServer(app);
}

class Satellite {
  constructor(options = {}) {
    // If we're given a healthCheck function, we'll use it with terminus below.
    // NOTE: this function should return a Promise.
    this.healthCheck =
      typeof options.healthCheck === 'function' ? options.healthCheck : () => Promise.resolve();

    // If we're given a shutDown function, we'll use it with terminus below.
    // NOTE: this function should return a Promise.
    this.shutDown =
      typeof options.shutDown === 'function' ? options.shutDown : () => Promise.resolve();

    // Keep track of credentials if we're passed any
    this.credentials = options.credentials;
    // Use the router passed to us
    this.router = options.router || createRouter();
    // Expose the app
    this.app = createApp(this.router, options);
  }

  start(port, callback) {
    if (this.server) {
      throw new Error('server already started');
    }

    if (typeof port !== 'number') {
      throw new Error(`port number required, got ${port}`);
    }

    // Expose the server
    this.server = createServer(this.app, this.credentials);

    // Graceful shutdown and healthcheck
    createTerminus(this.server, {
      healthChecks: {
        '/healthcheck': this.healthCheck,
      },
      signal: 'SIGINT',
      onSignal() {
        // Do any async cleanup required to gracefully shutdown. The calls to
        // redis/elastic shutDown() will be no-ops if no connections are open.
        return Promise.all([this.shutDown(), redis.shutDown(), elastic.shutDown()]).catch((err) =>
          logger.error({ err }, 'unexpected error while shutting down')
        );
      },
      logger: (...args) => logger.error(...args),
    });

    // Start the server
    this.server.listen(port, callback);
  }

  stop(callback) {
    const self = this;

    function finished() {
      self.server = null;
      if (typeof callback === 'function') {
        callback();
      }
    }

    if (!this.server) {
      finished();
      return;
    }

    this.server.close(finished);
  }
}

module.exports = Satellite;

Another solution could be to use set headers:

res.writeHead(200, 'Access-Control-Allow-Origin': '*', 'Access-Control-Allow-Methods': 'OPTIONS, POST, GET');

This is a plan I hope works but I have much to find out when I start working on the project. Stay tuned for my more in depth blog about working on the issue.

Contributing to Local Opensource Projects

Luigi Zaccagnini — Tue, 30 Nov 2021 03:57:16 +0000

Hello! During this blog post I will be discussing the two issues I decided to take for this release, the two pull requests that closed the issues and the two small code reviews I did in the Telescope Project!

To kill Two Birds with Two Stones

Picking two issues that challenged me more than my Hacktoberfest issues was not an easy process. The last challenge I left off on from Hacktoberfest was contributing a new provider to Notifire. Eventually I ended up choosing a Telescope issue and issue for a small opensource project.

Telescope Issue

The telescope issue was switching telescope from using body-parser to express.json(). This issue was not as difficult as I thought it was but, it taught me something really cool! Before this issue I would always use body-parser but after researching I learned that you could just use express. Once I understood that it was built in to express, implementing the solution for the PR was easy!

Awesome-Adoption

Awesome-Adoption the second project I worked on for this project. Awesome-Adoption is a opensource project that allows people to adopted pets. The issue I worked on required me to write tests that tested the donate page of the website. The main checks were:

Test for filtering
Drop down
Expecting the elements from the list

This was very intimidating for me as I am still pretty new to writing tests but, the challenge was on! I first was trying to test the donate page with render test and Jest. I had a lot of problems trying to simulate drop downs so I had to turn to the community for help. One of the members of the community guided me to user-event | Testing Library. This really helped me start to form the tests by writing.

test("Test for filtering", () => {
  render(<Donate />);

  userEvent.selectOptions(
    screen.getByTestId("dropdown"),
    screen.getByTestId("donate-test-selection-united-states", {
      name: "united states",
    })
  );

Above was one of the first tests I wrote using the userEvent tool. To grab elements in React, I used a testID to grab the elements. Although this worked and the tests were running, there was a better way to do this. A code review recommended me to use the getByRole option. This option allowed us to:

Get the option element without tags.
Send it the value we wanted selected.
Get the amount of options available.
Get the currently selected option.

userEvent.selectOptions(
    screen.getByTestId("dropdown"),
    screen.getByRole("option", {
      name: "united states",
    })
  );

 expect(
    screen.getByRole("option", {
      name: "united states",
    }).selected
  ).toBeTruthy();

expect(screen.getAllByRole("option").length).toBe(10);

This was so powerful and allowed code to be more readable. I also found a tool that allowed me to query the text in the document screen.queryAllByText. This allowed me to check and make sure that after I selected an option, the correct data could display. This pull request taught me a lot of neat tricks for writing tests and I recommend you go take a look and see it for yourself!

Code Reviews

I found that the two code reviews were very difficult for me. I felt that looking through the code and trying to improve it was very hard at first. The code looked good and if there was a problem it was very small. Eventually I found things that could help pull requests and improve the code!

First Review

My first review was a very small review. I found that in the pull request, the programmer was using the color : 'black' instead of #000000. This may be a bit picky but the style of css uses hexacode to define colors.

Second Review

My second review wasn't much bigger but taught me a ESLint rule. To start I found style mix matches with the margin in css using pixels or em. So I recommended sticking to one so there isn't a mix in units. The second comment was an ESLint error caused by unary operators. ESLint doesn't allow for unary operators causing the error in the code. To fix this I reccomended using variable += 1 instead of variable++.

Conclusion

This release was a very difficult challenge but taught me a lot about collaborating with new projects and that you never stop learning. Now that I am moving from this, I will be working on my final project of the semester. A difficult issue that will take me 3 weeks. See you next time!

Publishing Octo to NPM

Luigi Zaccagnini — Sat, 27 Nov 2021 03:19:48 +0000

Hello! Welcome to another blog post about Octo! In this blog post I am going to discuss what I used to publish Octo, the process of how I did it, how I tested it and how to install Octo for yourself!

Getting Ready for Publishing Octo

To start, I used NPM to release Octo to the public.

{
  "name": "octo-ssg",
  "version": "0.1.0",
  "description": "A tool that allows you to generate static sites based off of text data.",
  "main": "bin/app.js",
  "bin": {
    "octo": "./bin/app.js"
  },
  "scripts": {
    "prepare": "husky install",
    "start": "node ./bin/app.js",
    "build": "npm run prettier && npm run eslint-fix && npm run eslint",
    "test": "jest",
    "coverage": "jest --coverage",
    "eslint": "npx eslint .",
    "eslint-fix": "eslint --fix .",
    "prettier": "prettier --write .",
    "prettier-check": "prettier --check ."
  },
  "repository": {
    "type": "git",
    "url": "git+https://github.com/LuigiZaccagnini/octo.git"
  },
  "keywords": [
    "ssg",
    "static",
    "site",
    "generator"
  ],
  "author": "Luigi Zaccagnini <contact@luigizaccagnini.com> (https://luigizaccagnini.com/)",
  "license": "GPL-3.0-or-later",
  "bugs": {
    "url": "https://github.com/LuigiZaccagnini/octo/issues"
  },
  "homepage": "https://github.com/LuigiZaccagnini/octo#readme",
  "dependencies": {
    "boxen": "^4.2.0",
    "chalk": "2.4",
    "enzyme": "^3.9.0",
    "react": "^16.8.6",
    "react-dom": "^16.8.6",
    "react-test-renderer": "^17.0.2",
    "showdown": "^1.9.0",
    "yargs": "^17.2.1"
  },
  "devDependencies": {
    "eslint": "^8.1.0",
    "husky": "^7.0.4",
    "jest": "^27.3.1",
    "prettier": "2.4.1"
  }
}

I had to go over my package.json to make sure that all my information was correct because this in the information that would be going live. So when you decide to go through with publishing your package, you should make sure your package.json is up to date with information. Once my package.json was good, I had to go through my code and test it to make sure I wasn't publishing a broken tool! Since I have already integrated tools into the project this part was easy (Read Using Static Analysis Tooling with Open Source!, Creating Tests for Octo and Octo: Continuous Integration for more information about adding tools to your project)! Most of my project altering was updating documentation to help users install Octo. Finally push an annotated tag for this release. Since this was Octo's first release I used git tag -a v1.0 -m "version 1.0" to set it as version and git push --follow-tags to push the tag to the repository.

Working with NPM

Now that my project was ready, I created an account at NPM and logged into it through terminal using npm login. You need to confirm you email address for the next steps to work or you will get a 403 error. Another problem I ran into was that if your package name already exists on NPM, you need to change it in your package.json or you will get a 403 Error. This error took me awhile to learn about because the error just stated that I didn't have permission to upload my package. Now that I was logged in and everything is setup correctly, I ran npm publish and Octo was published!

User Testing

For the best user testing I got my sister who is learning web development to try installing my project. I thought this would be perfect because she is using another operating system and I can get a fresh opinion. The main problem I had with the testing was documentation to guide the user to install Octo. When my sister tried to install it on her PC, it wouldn't work because it was not globally installed. So I just fixed the documentation to globally install the project.

How to Install Octo on Your Computer

To install Octo is pretty easy:

Make sure you have Node LTS downloaded and setup on your computer.
Open your terminal/cmd and enter npm i octo-ssg -g
Once installed convert a markdown file to html using octo -i markdownFile.md

Adding CI with NPM Releases

Creating a CI for each release was simple using Github actions. They provided me a template for NPM releases and that was it.

name: Node.js Package

on:
  release:
    types: [created]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v2
        with:
          node-version: 14
      - run: npm ci
      - run: npm test

  publish-npm:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v2
        with:
          node-version: 14
          registry-url: https://registry.npmjs.org/
      - run: npm ci
      - run: npm publish
        env:
          NODE_AUTH_TOKEN: ${{secrets.npm_token}}

  publish-gpr:
    needs: build
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v2
        with:
          node-version: 14
          registry-url: https://npm.pkg.github.com/
      - run: npm ci
      - run: npm publish
        env:
          NODE_AUTH_TOKEN: ${{secrets.GITHUB_TOKEN}}

As you can see above, whenever I push a tag to releases this code will publish Octo to NPM.

Conclusion

I thought this lab would be very difficult because of the daunting idea of having my package on NPM seemed so crazy. The tool I always use for my projects is hosting one of mine, like wow. I am very proud of this achievement and I am very excited with what I can now do with this knowledge. If you have ever published a NPM package comment about what package it is! Thanks for reading, until next time!

Octo: Continuous Integration

Luigi Zaccagnini — Sat, 20 Nov 2021 04:49:06 +0000

Welcome to another post about my project Octo! In this blog I am going to go over:

The process of integrating CI(continuous integration) into my open source project Octo
How writing tests for another repository felt
Thoughts of CI

Continuous Integration

Setting up CI with Github actions was extremely easy. Github has prefabs of node configurations making CI easy to integrate in your project. If you followed my previous blogs about testing and static analysis tooling, creating your config should be short.

Navigate to your Github repository and click the actions button beside projects.
Click on the basic node configuration. Once you click on that, it should bring you to a new page with the creation of a .yml file.

name: Node.js CI

on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [12.x, 14.x, 16.x]
        # See supported Node.js release schedule at https://nodejs.org/en/about/releases/

    steps:
      - uses: actions/checkout@v2
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v2
        with:
          node-version: ${{ matrix.node-version }}
          cache: "npm"
      - run: npm ci
      - run: npm run prettier-check
      - run: npm run eslint
      - run: npm test

Octo's .yml looks like the above code. Most of the code above was provided by Github as a template to start with. I only added my npm commands created before as checks for the CI so, if you haven't done that yet you should go read those blogs! Once this is done, your CI should be now included in your repository!

Writing Tests in Another Repo

Working in another person's repo was a little tough. The repo's contributing.md was outdated so I had to find the files and commands to use for testing the project. Once I was able to figure that out writing a new test was not as difficult because of Jest's --coverage flag. This helped generate a report to find all the missing coverage for tests in the project. This also helped me understand how the project works and how to write tests for it.

Final Thoughts on CI

I think everyone should have CI integrated in their projects, even if it is being developed solo. I believe this is important for each project because it helps keep broken code from being pushed to a repo. Although developers may feel that they won't run into this, keeping a mind set of writing tests while developing a project makes your code better.

Creating Tests for Octo

Luigi Zaccagnini — Wed, 17 Nov 2021 00:54:10 +0000

Hello! Welcome to another blog post about my open source project Octo. If you're new to my blogs, Octo is an open source static site generation tool created by me! Today I am going to review the process of writing tests and explain how I implemented them in my project.

What Framework to Use?

The framework I picked for my project was Jest. I picked Jest because it is the framework I am most comfortable with and it is very easy to setup in your project!

Jest Setup

To add Jest to your project, run yarn add --dev jest or npm install --save-dev jest. Once Jest is installed, open your package.json and create a new npm script "test":"jest". Now whenever you want to run your tests all you need to do is run npm test. I strongly recommend storing all of your test files in your root directory in a test folder. It will help keep your project nice and organized.

Writing Tests

Everything up until this point was simple for me. Once I started writing tests I ran into a bunch of errors that confused me. Good thing I ran into those so you can now learn from my mistakes! To start off, create a file in the format of myFileThatNeedsTesting.test.js. Once done, open the file and add /* eslint-disable no-undef */ at the top. If you do not do this, eslint will think you're making a bunch of errors and might make you a little confused.

Writing a Matchers

test('Checks if it can add a directory', () => {
  expect(ff.addDirectory('./dist')).toBeUndefined();
});

A matcher is a test that checks its value to see if it is correct. As you can see above, I created a test to check if my addDirectory function would return undefined. I check for undefined because the addDirectory function will only return errors. So if I do get anything, there is a problem. This is a very basic matcher but, if you're interested in more matcher options check here.

Snapshots

it('Markdown to HTML renders correctly', () => { 
ff.markdownToHTML('test/markdownTest.md').then(html => {
  const tree = ReactTestRenderer
    .create(html)
    .toJSON();
  expect(tree).toMatchSnapshot();
  });
});

Snapshot testing was my favourite part! I found it really useful to compare test render code with the correct code. Above I use my markdownToHTML function to convert a markdown file and then make sure, it matched the snapshot. At first I was having problems with this because my functions could not find the file. I eventually figured out that I need to path from the root of my project. Once I had that working, the file was correctly displaying the correct information.

Generating a Coverage Report

Generating a coverage report is very simple and gives you a lot of information about how and where you can write more tests for your code. To generate the report use yarn test --coverage. After running that command you should see a folder with all the information.

Conclusion

Setting up tests for my code was a very fun process. It taught me the importance of testing code as well as a different approach on how to write code. I have attempted to write tests for code before but would always get stuck. Now that I finally have learned how to write tests properly, I will continue to write tests for future projects and encourage others to do the same!

Using Static Analysis Tooling with Open Source!

Luigi Zaccagnini — Fri, 05 Nov 2021 22:08:39 +0000

Welcome to another blog post about the journey of Octo, the open source tool for static site generation! Today I will be going over how I added static analysis tooling into the project and how you can do the same for your open source projects!

Tools Overview

To start, I am going to go over all the tools that I added to Octo and show you how to add them to your project. I will also be providing links if you want more configuration options or more information on the projects.

Eslint

Eslint is a great tool for checking errors in your code! I would strongly recommend you use eslint in your developer environment and all projects you work on. I have been using eslint as my linter for a few year now with all my code and it has helped me keep my code in good shape. To add eslint to your project run npm install eslint --save-dev. Now that eslint is in your dev dependencies, you can run npx eslint --init. This will prompt you to create a config file that works for your project. If you now run npx eslint . eslint will check all the files in your project for errors!

Octo's .eslintrc.json looks like this:

{
  "env": {
    "browser": false,
    "node": true,
    "es2021": true
  },
  "extends": "eslint:recommended",
  "parserOptions": {
    "ecmaVersion": 13,
    "sourceType": "module"
  },
  "rules": {}
}

I set "browser" : false and "node": true because my project is a tool that uses node and doesn't use the browser to operate.

Prettier

Prettier is a code formatter that supports a ton of languages including javascript! We are using this as it helps make our code readable and it allows us to enjoy one style of coding!

To install Prettier run:

npm install --save-dev --save-exact prettier
echo {}> .prettierrc.json to create an empty config file.
echo >> .prettierignore to creat a ignore file exactly like gitignore.

Octo's .prettierrc.json is currently empty because the current formatting for me is good. The .prettierignore is just a copy of our .gitignore so for your project you can do the same!

Now prettier should be in your project! To use prettier run:

npx prettier --write . to format and save all your files.
npx prettier --check . to see if your project is formatted.

Writing NPM Commands

Now that we have our two first awesome tools, we should write some scripts so we aren't constantly writing multiple commands at once! head over to your package.json in your preferred text editor and look for the scripts section. It should look like this:

"scripts": {
    "start": "node ./bin/app.js"
  },

Once we are there we can start writing some scripts to help us reduce the amount of commands we are writing. To start lets write a basic test script.

"scripts": {
    "start": "node ./bin/app.js",
    "test": "prettier --check && npx eslint ."
  },

The "test" part of the command can be named anything you like but should be related to what it runs. Our test command runs prettier --check to check if all files are formatted. We then use && npx eslint . to use eslint to check our project. If we now run npm run test it will run both commands with a single line! Now lets go to the next level!

"scripts": {
    "start": "node ./bin/app.js",
    "test": "npm run prettier-check && npm run eslint",
    "eslint": "npx eslint .",
    "prettier-check": "prettier --check ."
  }

Now that we know how to write one command, why not use those commands with other commands. With this script we wrote two new commands eslint and prettier-check. eslint runs eslint check and prettier-check checks the files to make sure they're formatted! Now we can call those commands in the test command using npm run. You can also use the commands separately now if you don't want to run both at the same time.

As you can see, you can get very creative with it as you can see with Octo's scripts:

"scripts": {
    "prepare": "husky install",
    "start": "node ./bin/app.js",
    "build": "npm run prettier && npm run eslint-fix && npm run eslint",
    "test": "npm run prettier-check && npm run eslint",
    "eslint": "npx eslint .",
    "eslint-fix": "eslint --fix .",
    "prettier": "prettier --write .",
    "prettier-check": "prettier --check ."
  }

Husky

Wow that is a lot of information about two tools! Now how cool would it be if your project would automatically run these tools whenever you made a push or commit? Well here comes Git hooks to the rescue with the power of Husky! To install husky run npm install husky -D. That doesn't fully install husky, to fully install it we have to run another command. Since we just learned about writing scripts in our package, we should write a new one for preparing our project.

"scripts": {
    "prepare": "husky install",
    "start": "node ./bin/app.js",
    "test": "npm run prettier-check && npm run eslint",
    "eslint": "npx eslint .",
    "prettier-check": "prettier --check ."
  }

Now that we have husky install as a command, we can run npm run prepare to get husky fully installed. It should have a generated .husky folder in the root of your project. Now lets write our first hook!

Run this command to create a pre-commit script for husky:

npx husky add .husky/pre-commit "npm test"

This command creates a file within the .husky folder and names it pre-commit. It sets the command npm test to run every single time you commit within the project.

Customize your Developer Environment!

Now that we have our cool customized developer environment for our project, we want to make sure people working on our project are using the tools we utilized today. To do that we need to create .vscode folder with our rules. This part is easy depending on how much rules you want to add to your project. To start you should create a folder called .vscode and within it create two files named settings.json and extensions.json.

Settings

{
  "editor.formatOnSave": true,
  "files.autoSave": "afterDelay",
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.formatOnPaste": true,
  "editor.inlineSuggest.enabled": true
}

These are Octo's rules. These rules are inherited from my personal profile. The rule that is very important here is "editor.defaultFormatter": "esbenp.prettier-vscode". This makes sure that when someone is working in your project that they're using prettier as the default formatter. The other lines in the file are about auto formatting so if you forget to save often like me you might want to use them! If you want to use your own settings on VS Code you can open command palette and type settings.json. It should give you options on which settings you would like to open. You can then copy that into your settings.json within the .vscode folder we created earlier.

Extensions

{
  "recommendations": [
    "dbaeumer.vscode-eslint",
    "esbenp.prettier-vscode",
    "streetsidesoftware.code-spell-checker"
  ]
}

This is Octo's recommendations for extensions. Whenever someone opens your project in VS Code it will ask them to download the recommended extensions for the project. One extension I didn't talk about was code-spell-checker. This extension is great for checking for spelling errors within your code.

Extra Information

If you enjoy these extensions you can download them through the extensions tab on VS Code. I have used these tools in my personal developer setup for an extremely long time and they have helped me a ton. I used them on Octo before I went to an automatic setup so the tools didn't find any problems yet. Having them installed doesn't hurt and will only help you!

Conclusion

Now you have an awesome project that uses tools to automatically make sure whoever is working on your project is following your rules! If you want to contribute to Octo you can here. If you have recommendations for other tools or want to share your developer setups, I would love to read them in the comments! Thanks for reading!

Final Hacktoberfest Pull Requests!

Luigi Zaccagnini — Tue, 02 Nov 2021 03:35:07 +0000

Wow! What an amazing month! We finally finished Hacktoberfest and it was one crazy ride! During this blog post I will be going over the issues and final PR I did for Hacktoberfest.

The issues that were taken

The two issues I took were:

Notifirehq

This issue was a big step for me as I was contributing to a project I have never contributed to and was adding a feature to the repository. I had to integrate support for the whispir provider. It took a lot of time preparing and reviewing their rules to contributing. Since it is a small project there is not much support for it but, the people who are working on it are very motivated and inspired to work on it. If I ever had any questions the community was there always helping me! Submitting the first pull request took some time as I didn't have a template and I had to do research for the provider that needed to be added. The pull request is still being finished currently because I am fixing changes that are requested. You can find the pull request here.

Telescope

Near the end of Hacktoberfest I was able to pick up two issues from the telescope project updating outdated dependencies. I wasn't able to create a pull request as I am currently in the process moving so I did not have the time to complete the issues but, will update you guys in a future blog post about the completion.

Conclusion

Hacktoberfest was a lot of fun to contribute to and learn new code. This year was a rough start because some projects I tried to contribute to were not respondent or required a lot more time and support from the community. Although I had those tough obstacles, I am hoping next year to complete a lot more pull requests and to contribute to projects I personally use. Thank you for reading my last Hacktoberfest blog until 2022!

Inspired to improve Octo!

Luigi Zaccagnini — Sun, 31 Oct 2021 18:43:52 +0000

Hello! In this blog post I am going to go over how it was to work with Docusaurus and adding an upgrade to Octo inspired by Docusaurus! Working with Docusaurus was a lot of fun and I hope you learn a lot from this post so you can use it for your open source projects too!

Docuwhatus?

Docusaurus is a tool that allows anyone to build a static website with a text format called Markdown! This tool has many purposes but, I think I would mostly use this for writing documentation for my projects!

Starting with Docusaurus

Making a base static site with Docusaurus is super easy and fun to learn! To start you need a Node.js version >= 12.13.0 or Yarn version >= 1.5 . You can check both of these versions by using node -v or yarn —version. I personally had trouble with this as I was using another version of node for another project I was working on. To fix this I ended up using Node Version Manager (nvm) to help with switching between versions of node. After making sure npm or yarn are their correct versions run:

npx create-docusaurus@latest project-name classic

and a basic package will be created for you. Once the package is downloaded cd project-name and run npm run start and you will have your awesome basic project running! There is so much more features you can do with Docusaurus and I highly encourage you to check out the docs and play around with it! Here is my Docusaurus demo and here is the project repo!

Adding a new Feature to Octo

After playing around with Octo I got inspired to add something cool to Octo that would make it more fun to use! To start I think the most important feature that needed to be added as soon as possible was full Markdown support. This was a very needed feature because only having one Markdown feature was annoying and made Octo a less desirable tool. So to start I had to research a package that could translate text into markdown. Eventually I found Showdown and adding this feature was 100 times easier! Adding the full Markdown support for me was very easy, I just had one bug I had to fix regarding how it processed multiline Markdown.

So if I had:

\```


Hello


```\

It would not process this correctly because my code was processing the Markdown by line and not by the entire document. So I had to feed Showdown the entire file opposed to line by line.

Future for Octo

Now that I have Markdown finished for Octo I have filed some issues for the next steps of what I would like to be down for the tool.
Some of the features I want are:

Search Engine Optimization
Liquid tags support
More code refactoring

If you are interested to tackle these issues, just follow the link and ask to take on the feature! Thanks for reading another one of my blogs!

Octo
Octo Feature PR
Docusaurus Demo
Docusaurus Repo