Release 0.4a: #telescope - My PR life cycle: create, review, land and learn!

Project Telescope - a web app for tracking blogs in orbit around Seneca's open source involvement - started more than a month ago has shown a lot of progress while getting contributions from many students including me working mostly in the aspect of developer experience.

It is amazing to me how far we have gone with many people put in their effort a little bit here and there.

Last 2 Weeks Recap

Two weeks ago, I posted about the integration of ESLint, Prettier and EditorConfig into the project and was waiting for everyone's codes to come in before I can run re-formatting on the entire codebase. Two days later, after a productive hand-on meeting with my professor, the PR landed with code styling in the entire codebase uniformed under 1 format and me learning a few useful things.

The first thing I picked up during the meeting is the set up of a script to run prettier on selected code modules using npm.

{
  "name": "telescope",
  "version": "0.0.1",
  // ...
  "scripts": {
    "prettier": "prettier --write \"./**/*.{md,json,html,css,js,yml}\"",
  },
  // ...
}

The script above in combination with a following .prettierignorefile would do the task of running Prettier on all *.md, *.json, *.html, *.css, *.js and *.yml files in the codebase except for package.json, package-lock.json files, node_modules and coverage folder.

package.json
package-lock.json
node_modules/
coverage/

Besides that, I also learnt an amazing tool called Husky allowing the developers to set up hooks for git events. Using this for Telescope, I set up a pre-commit hook that runs Prettier on every file in the staging area before performing the commit.

{
  "name": "telescope",
  "version": "0.0.1",
  "scripts": {
    "prettier": "prettier --write \"./**/*.{md,json,html,css,js,yml}\"",
  },
  "husky": {
    "hooks": {
      "pre-commit": "pretty-quick --staged"
    }
  },
  // ...
}

This addition will not only uniform code styling but also automate the process of beautifying code. The developers from now on do not need to be aware of the fact that Prettier is backing the codebase nor how to use it. For every commit they do, the code styling will be adjusted accordingly.

Release 0.4

For release 0.4, I built it up on my release 0.3 by doing 2 issues:

Add a .vscode folder with VSCode Workspace recommendations

As for the first one, Visual Studio Code (VS Code) is a known powerful code editor providing great capabilities for the users to customize their workspace. One of those said great capability is to allow the users to add a folder named .vscode storing all custom VS Code settings into the workspace of the project so that those settings can be shared among all developers given that they use VS Code.

The shared settings include:

• Editor settings such as indent width, indent type, newline character... etc.
• Recommended extensions for the project
• Launch command for VS Code debugger

But hold on, wait a minute! Why do we need to return to the topic of sharing setting for indent width, indent type and newline character? Didn't a post last week fix this issue with EditorConfig extension? You are not wrong! However, the EditorConfig is still an extension. If the developer, for any reason, does not have it installed and enabled, those settings will not be overwritten.

With the .vscode folder, as long as the developer uses VS Code as their editor, which I believe the majority of the current developer team does, the settings should be applied regardlessly.

Another capability of VS Code is allowing easy integration and management of extensions. For different projects, we may need and use different extensions (There is no point in using an extension like C++ IntelliSense while doing frontend web development, right?). Therefore, VS Code allows the setting of a set of recommended extensions for a specific project.

Using the .vscode folder, we can compose this list so that whenever the project is open with VS Code while it does not have the recommended extensions installed, a notification will show up suggesting the developers install them.

Finally, VS Code offers a powerful debugging tool to step through and track variables in a program initiated with just a button. .vscode folder allows the configuration of the command the button will trigger. Usually, the command is the one that will trigger debugging mode of the program and/or start a debugging server.

Update eslint and stylelint configs for Prettier plugins

As a build-up for the previous work with ESLint, this week, I also worked on Stylint to better customize and uniform formatting of CSS code.

Stylint is a linting tool designed specifically for CSS with powerful syntax support and multiple rules for easy customization. Even more excited, Stylint can be integrated into Prettier so that when Prettier is run, the rules of Stylint are also applied.

Besides that, with this integration, it is guaranteed that there would be no conflict between the 2 tools (Prettier and Stylint) since all basic formatting rules are delegated to Prettier, leaving only semantic rules handled by Stylint.

The integration process is pretty straight-forward with the need for some extra packages and configuration changes in .stylelintrc.js:

module.exports = {
  extends: ['stylelint-config-prettier', 'stylelint-prettier/recommended'],
  plugins: ['stylelint-prettier'],
  rules: {
    'prettier/prettier': true,
  },
};

Note that the configuration above also makes use of the stylint-recommended settings which goes along with the stylint/prettier package.

That is it for my work this week! Although it is small, I think that I get to learn many small techniques that I can apply to future (group) projects. I believe with this knowledge, projects, later on, will be less of a nightmare for me... and my teammates!