DEV Community: Rahul Tarak

Depp - How it was built

Rahul Tarak — Wed, 03 Nov 2021 04:54:52 +0000

Just briefly wanted to talk about how this built and how it works, of course the entire codebase is open-source so feel free to poke around yourself

So this package works by wrapping around the esbuild go api to add this extra functionality, so yes technically we built your whole code base to parse what dependencies you are using. This might sound incredibly stupid, but considering esbuild speed and flexibility, it is still significantly quicker than most solutions written in javascript

I realize this is not a great benchmark but considering most other tools don't have good monorepo support it was the best I can do. I compared depp (this tool) vs depcheck (a popular javascript tool with almost 3k stars) on a previous project https://github.com/wei/socialify

depp  0.42s user 0.36s system 135% cpu 0.576 total
depcheck  1.69s user 0.13s system 116% cpu 1.567 total

This tool was about 2.7x faster than depcheck while practically building the entire codebase

Using esbuild like this also allows me to build this tool, without writing an entire javascript/typescript parser

Setup

First we need to get the paths of all the package.json files and then all the source files,

I did this using something I built for an older project which is a modification of go standard library's [Glob](https://github.com/CryogenicPlanet/depp/blob/master/utils.go#L79-L87) This modification allow me to easily find all nested package.json and source files

Now we can read the package.json files and get all the packages in the repository, we can store these as a hash map or dictionary to compare against in the future.

Finally, we can pass the source files to esbuild as entry points and have it do its magic

Callbacks

First we use Resolve and Load callbacks from the esbuild api to check for packages as they are being imported.

There are some caveats here tho, we don't want to go down a rabbit hole of every import. Any import from node_module we don't care about, these are generally nested imports of modules importing other modules. So we can mark these files as external

Another optimization we can add is, any non .ts, .tsx, .js,.jsx file can be completely ignored. This is a bit painful in go because it does not support regex lookaheads (?)

Now with any actual import, we can check the kind of resolve it is, whether it is a import-statement , require-call or something else we don't care about. Finally we can check if the imported path contains any of our packages

Metafile

Additionally we use the esbuild meta file to do a second pass on any import we might have missed or that slip through or resolve callbacks. The esbuild meta file contains a bunch of information about inputs and their imports which we can use to see if a given package has been used or not

Duplicates

While the process of finding unused packages is quite involved, finding duplicates is quite easy on the other hand. It is just about correctly inputting the parsed package.jsons and checking for duplicates and storing their versions. There is a bit more work for check unused @types packages but it mostly similar to duplicates

Not going to go into it much here, that said it probably constitutes its own post of how to bundle go binaries with an npm package and how to release them

All that said this was a fairly fun project to make in the 8 or so hours it took, and it has already been fairly useful internally. Hope you find some use in the tool itself or maybe how I built it

If you want to try out the tool checkout

CryogenicPlanet / depp

A fast unused and duplicate dependency checker

Depp - Basic Usage and Features

Rahul Tarak — Wed, 03 Nov 2021 04:54:23 +0000

Recently we ran into a couple of bugs on our main fairly large monorepo which were caused my the same package existing twice but having different versions. This made me search for some dependency checking tools, and while there are existing ones none of them really had good monorepo support.

So I decided to make one, this is a brief about how I made it and also how to use it.

If you want to just try the tool without hearing ramble about it, feel free to checkout the repo

CryogenicPlanet / depp

A fast unused and duplicate dependency checker

Basic Usage and Features

Install

npm install -g depp-installer
depp --help  # Will should all avaliable options

Usage

Default Config

depp

Will check only typescript (.ts, .tsx) files in your root folder and all its children. It will also read the packages from then root package.json but also any package.json inside child folder (It supports mono repositories by default)

It will show unused packages, unused @type packages and duplicate packages with different versions

It will also generate a temporary html report file and open it in your browser. This file will look something like the following

https://cryogenicplanet.github.io/depp/static/htmlReport.html

Some Major Flags

--js Will enable checking js files
--dev Will enable checking dev dependencies (this is not very accurate)
--report Will save the report to .depp/report.md
--externals Can use this to external certain packages, useful if the build fails by default
--ignore-namespace Can ignore namspaced internal packages using thing, good for ignore @monorepo packages
--show-versions Will explicitly print the versions of duplicate packages in console

This is not an exhaustive list of all flags, for that run depp --help

Example advance usage is

depp  -e mobx -e magic-sdk -e domain -e @daybrush/utils -e yjs -e constants -e ws -v -in @editor -in @server -j -e perf_hooks --report

In the next part, I will dig a little deeper into how this tool was built and how it works under the hood

A utility type for widening types

Rahul Tarak — Wed, 18 Aug 2021 00:00:07 +0000

I love typescript, it makes my life super easy and makes my dev experience far superior. That said one gripe I've always had in complex typescript codebase is with nested types, especially using things like Pick or Omit you had to check the type definition, 4-5 levels deep to actually know what the type is, this can be quite annoying.

Recently I found a solution a great solution to this called Type Widening and it can be super easily implemented.

If you just want the basic type, here you go. That said I will break down how this works and how you can improve it below. You can also find a more advanced version of this with recursion and enum guards at bottom of the post.

export type ToPrimitive<T> = 
  : T extends string
  ? string
  : T extends number
  ? number
  : T extends boolean
  ? boolean
  : T extends (..._args: any[]) => any
  ? (..._args: Parameters<T>) => ReturnType<T>
  : T

/**
 * Expands a type so you can nicely seem the primitives
 */
export type Widen<T> = {
  [key in keyof T]: ToPrimitive<T[key]>
}

Usage

Usage is very simple just wrap the type you want with Widen<MyType> below is an embedded example which allows you to hover over the two types to see the difference

Extending the use of Widen

Enums

We use Enum quite a bit in our codebase and unfortunately there is no T extends enum in typescript, so to hack around it you much create a Blacklist type which you can skip over

// Unfortunately this is the only way I could find right now
type EnumBlackList = DogBread | CatBread | OtherEnums

Recursion

We can modify ToPrimitive to make it recursive like this

type ToPrimitive<T> = T extends string
  ? string
  : T extends number
  ? number
  : T extends boolean
  ? boolean
  : T extends (..._args: any[]) => any
  ? (..._args: Parameters<T>) => ReturnType<T>:
    T extends object // Check if object and call itself
    ? { [key in keyof T]: ToPrimitive<T[key]> }
  : T;

You can play with a demo below, which has all three different iterations setup for you

How it works

Not going into too much detail here, just a brief summary

This uses a combination of unity types from Typescript with conditional types to enable this

T extends string checks if the type is based on type string, which can be used as a conditional check. This allows us to check our base primitives like string number and boolean

To add support for functions, we need to check if the type has the structure of a function which we are doing by checking T extends (...args: any[]) => any Then we are returning the function with its correct parameters and return type using the Parameter and ReturnType utility type

Final Type

type EnumBlacklist = // your enums go here like Enum1 | Enum2 | Enum 3

type Widen<T> = { [key in keyof T]: ToPrimitive<T[key]> };

type ToPrimitive<T> = 
    T extends EnumBlackList ? T :
    T extends string
  ? string
  : T extends number
  ? number
  : T extends boolean
  ? boolean
  : T extends (..._args: any[]) => any
  ? (..._args: Parameters<T>) => ReturnType<T>
    T extends object
    ? { [key in keyof T]: ToPrimitive<T[key]> }
  : T;

type Test = Widen<MyType>

Feel free to email me any questions or suggestion on how I can improve this type or post at rahul@modfy.video

An actual complete guide to typescript monorepos

Rahul Tarak — Thu, 03 Jun 2021 00:23:44 +0000

When I was setting up our production monorepo at modfy.video, I found most typescript monorepo guides were quite lacking in addressing a lot of more detailed problems you run into or how to solve them with modern solutions.

This guide aims to do that for 2021, with the best in class tooling at this time. That said when using modern advanced tooling, you can and will run into some compatibility problems so this guide might be slightly esoteric for you.

This guide is really optimized towards typescript monorepos that also contain packages that can be deployed but really should work for any typescript monorepos.

Getting started

For this guide, we will be using pnpm but this should mostly work the space with yarn just swap out pnpm workspaces with yarn workspaces. (This will likely not work well with npm and would not recommend using that)

Base directory

To get started we need to setup our base directory it will contain a few key files, which will be explained in more detail below.

Your base directory once completed will look something like

.
├── jest.config.base.js
├── jest.config.js
├── lerna.json
├── package.json
├── packages
│   ├── package-a
│   ├── package-b
│   ├── package-c
│   ├── package-d 
├── pnpm-lock.yaml
├── pnpm-workspace.yaml
├── README.md
└── tsconfig.json

We can start by setting up our package.json

Feel free to swap pnpm out with yarn

{
  "name": "project-name",
  "repository": "repo",
  "devDependencies": {},
  "scripts": {
    "prepublish": "pnpm build",
    "verify": "lerna run verify --stream",
    "prettier": "lerna run prettier",
    "build": "lerna run build",
    "test": "NODE_ENV=development lerna run test --stream"
  },
  "husky": {
    "hooks": {
      "pre-commit": "pnpm prettier",
      "pre-push": "pnpm verify"
    }
  },
  "dependencies": {},
  "private": true,
  "version": "0.0.0",
    "workspaces": [
    "packages/*"
  ]
}

Some basic dependencies we can install are

pnpm add -DW husky lerna
# Nice to haves
pnpm add -DW wait-on # wait on url to load
pnpm add -DW npm-run-all # run multiple scripts parrellely or sync
pnpm add -DW esbuild # main build tool

These are definitely not all the dependencies but others will be based on your config

Finally your .gitignore can look like this

node_modules
lerna-debug.log
npm-debug.log
packages/*/lib
packages/*/dist
.idea
packages/*/coverage
.vscode/

Setting up workspace

Setting up pnpm workspaces are really easy you need pnpm-workspace.yaml file like

packages:
  # all packages in subdirs of packages/ and components/
  - 'packages/**'
  # exclude packages that are inside test directories
  - '!**/test/**'
  - '!**/__tests__/**'

Full documentation can be found here https://pnpm.io/workspaces

Orchestration

There are a few options for orchestration tools you can use like rushjs but for this guide we'll just use lerna. Specifically tho, we are not using lerna for package management or linking but just for orchestration.

Similar to the about workspace file we need a lerna.json where we set the packages

{
  "packages": ["packages/*"],
  "npmClient": "yarn",
  "useWorkspaces": true,
  "version": "0.0.1"
}

Note as we don't care about lerna for package management, the npmClient doesn't really matter.

The only lerna command we care about is lerna run <command> this lets us run a script across all our packages. So lerna run build will build all the packages in our repository

Setting up Typescript

The example below is for work with react, please change the configuration accordingly if you don't need react at all.

For typescript monorepos, we should use a relatively new typescript feature called project references, you can learn more about it here https://www.typescriptlang.org/docs/handbook/project-references.html

Few things to not about it are:

The only tsc command you have is tsc --build which is typescript's multistage build
You also have to use the composite flag which has a few added requirements https://www.typescriptlang.org/docs/handbook/project-references.html

To use project references you have to manually add the path to each reference like the following

// tsconfig.json
{
  "compilerOptions": {
    "declaration": true,
    "noImplicitAny": false,
    "removeComments": true,
    "noLib": false,
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "target": "es6",
    "sourceMap": true,
    "module": "commonjs",
    "jsx": "preserve",
    "strict": true,
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "allowSyntheticDefaultImports": true,
    "esModuleInterop": true,
    "lib": ["dom", "dom.iterable", "esnext", "webworker"],
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true,
    "isolatedModules": true
  },
  "exclude": ["node_modules", "**/*/lib", "**/*/dist"],
  "references": [
    { "path": "./packages/package-a/tsconfig.build.json" }, 
        // if you tsconfig is something different
    { "path": "./packages/package-b" },
    { "path": "./packages/package-c/" },
    { "path": "./packages/interfaces/" },
  ]
}

Finally it is good to add these dependencies as global dependencies

pnpm add -DW @types/node typescript

Eslint + Prettier (Optional)

Feel free to use your own prettier and eslint config here, but this is just the one I like and use.

Dependencies

pnpm add -DW eslint babel-eslint @typescript-eslint/eslint-plugin @typescript-eslint/parser eslint-config-prettier eslint-config-prettier-standard eslint-config-react-app eslint-config-standard eslint-plugin-flowtype eslint-plugin-import eslint-plugin-jsx-a11y eslint-plugin-node eslint-plugin-prettier eslint-plugin-promise eslint-plugin-react eslint-plugin-react-hooks eslint-plugin-simple-import-sort eslint-plugin-standard prettier prettier-config-standard

// .prettierrc
"prettier-config-standard"

// .eslintrc
{
  "env": {
    "browser": true,
    "es6": true,
    "node": true
  },
  "extends": [
    "react-app",
    "plugin:react/recommended",
    "plugin:react-hooks/recommended",
    "prettier-standard"
  ],
  "parserOptions": {
    "project": "./tsconfig.json"
  },
  "plugins": [
    "react",
    "@typescript-eslint",
    "react-hooks",
    "prettier",
    "simple-import-sort"
  ],
  "rules": {
    "no-use-before-define": "off",
    "prettier/prettier": [
      "error",
      {
        "endOfLine": "auto"
      }
    ],
    "simple-import-sort/exports": "error",

    "simple-import-sort/imports": [
      "error",
      {
        "groups": [
          // Node.js builtins. You could also generate this regex if you use a `.js` config.
          // For example: `^(${require("module").builtinModules.join("|")})(/|$)`
          [
            "^(assert|buffer|child_process|cluster|console|constants|crypto|dgram|dns|domain|events|fs|http|https|module|net|os|path|punycode|querystring|readline|repl|stream|string_decoder|sys|timers|tls|tty|url|util|vm|zlib|freelist|v8|process|async_hooks|http2|perf_hooks)(/.*|$)"
          ],
          // Packages
          ["^\\w"],
          // Internal packages.
          ["^(@|config/)(/*|$)"],
          // Side effect imports.
          ["^\\u0000"],
          // Parent imports. Put `..` last.
          ["^\\.\\.(?!/?$)", "^\\.\\./?$"],
          // Other relative imports. Put same-folder imports and `.` last.
          ["^\\./(?=.*/)(?!/?$)", "^\\.(?!/?$)", "^\\./?$"],
          // Style imports.
          ["^.+\\.s?css$"]
        ]
      }
    ],
    "import/no-anonymous-default-export": [
      "error",
      {
        "allowArrowFunction": true,
        "allowAnonymousFunction": true
      }
    ]
  }
}

// .eslintignore
*/**.js
*/**.d.ts
packages/*/dist
packages/*/lib

Testing (Optional)

Here's a configuration for basic testing with jest

pnpm add -DW jest ts-jest @types/jest tsconfig-paths-jest

// jestconfig.base.js
module.exports = {
  roots: ['<rootDir>/src', '<rootDir>/__tests__'],
  transform: {
    '^.+\\.ts$': 'ts-jest'
  },
  testRegex: '(/__tests__/.*.(test|spec)).(jsx?|tsx?)$',
  moduleFileExtensions: ['ts', 'tsx', 'js', 'jsx', 'json', 'node'],
  collectCoverage: true,
  coveragePathIgnorePatterns: ['(tests/.*.mock).(jsx?|tsx?)$'],
  verbose: true,
  testTimeout: 30000
}

// jest.config.js
const base = require('./jest.config.base.js')

module.exports = {
  ...base,
  projects: ['<rootDir>/packages/*/jest.config.js'],
  coverageDirectory: '<rootDir>/coverage/'
}

Packages

Now that we have setup the base repo, we can setup the individual packages

We will cover few broad types of packages here:

Typescript only packages, that is packages that don't need to be deployed with javascript support. Examples, interfaces, or internal only packages
Packages that depend on other packages
Packages with testing
Packages with build steps
Packages that are meant to be deployed to support javascript

Regardless of the type of package, all packages will consist of same basic config

├── package.json // can be a standard package.json
├── README.md // can be whatever
├── src
│   ├── index.ts
├── tsconfig.json

For the tsconfig.json it should be structured like

// tsconfig.json
{
  "extends": "../../tsconfig.json",
  "compilerOptions": {
    "outDir": "./dist", // Your outDir
  },
  "include": ["./src"]
}

For the package.json it can be structured normally but should ideally contain these scripts

// package.json
{
// other
"scripts": {
    "prettier": "prettier --check src/",
    "prettier:fix": "prettier --write src/",
    "lint": "eslint . --ext .ts,.tsx",
    "lint:fix": "yarn lint --fix",
    "verify": "run-p prettier lint", // using npm-run-all
    "verify:fix": "yarn prettier:fix && yarn lint:fix",
    "build": "", // whatever the build script is
  },
}

Typescript only packages

It depends on the use case but if this is like an interfaces package, it likely requires no other configuration. (not even a build script)

For packages that might need a build script to run regardless, there will be more guidance below.

Packages that depend on other packages

When @projectName/package-a depends on @projectName/package-b we should add the following steps to let typescript know about this dependency.

First in package-b we add the following to the tsconfig

// packages/package-b/tsconfig.json
{
  "extends": "../../tsconfig.json",
  "compilerOptions": {
    "outDir": "./dist",
    "composite": true // the composite flag
  },
  "include": ["./src"]
}

Second in package-a we reference this package like

{
  "extends": "../../tsconfig.json",
  "compilerOptions": {
    "outDir": "dist",
    }
  },
  "include": ["**/*.ts", "**/*.tsx"],
  "exclude": ["dist/*"],
  "references": [{ "path": "../package-b/tsconfig.json" }]
}

Packages with test

For packages that are using jest for testing

// packages/package-a/jest.config.js
// Jest configuration for api
const base = require('../../jest.config.base.js')

// Only use the following if you use tsconfig paths
const tsconfig = require('./tsconfig.json')
const moduleNameMapper = require('tsconfig-paths-jest')(tsconfig) 
module.exports = {
  ...base,
  name: '@projectName/package-a',
  displayName: 'Package A',
  moduleNameMapper
}

For testing you need to have to separate tsconfigs, this can be structured like default + build, or default + test. For this example, we will use default + build

// tsconfig.json
{
  "extends": "../../tsconfig.json",
  "compilerOptions": {
    "outDir": "./dist",
    "composite": true,
    "rootDir": ".",
    "emitDeclarationOnly": true,
  },
  "include": ["src/**/**.ts", "__tests__/**/**.ts"],
  "exclude": ["dist"]
}

Essentially we don't want to build our tests, so we can just ignore them to not cause errors

//tsconfig.build.json
{
  "extends": "./tsconfig.json",
  "exclude": ["**/*.spec.ts", "**/*.test.ts"]
}

After this whenever you are building use the tsconfig.build.json like tsc --build tsconfig.build.json

Packages with build steps

Obviously there are tons of typescript build tools and this category is very broad, even in our monorepo we have four-five different typescript build tools

Think of this more as a broad set of tools you can use to nicely achieve this

esbuild - I cannot stress how awesome esbuild is, its really great and fairly easy to get started with https://esbuild.github.io/
vite - I certainly didn't know vite had a library mode, but it does and it is very good. This would definitely be my recommendation for building any frontend packages for react/vue/etc

https://vitejs.dev/guide/build.html#library-mode
tsup - This is a minimal configuration build tool which wraps around esbuild and has some nice features.

(All these tools are built upon esbuild, it is really mind blowingly fast)

The only catch with esbuild and vite is you don't get a .d.ts file. You can generate a .d.ts file by adding "emitDeclarationOnly": true to tsconfig and then running tsc --build

If you are using tsup you can use the --dts or -dts-resolve flag to generate the same.

All this being said, I would follow this issue on swc another fast compiler because it might come with the ability to generate .d.ts files in the future. https://github.com/swc-project/swc/issues/657#issuecomment-585652262

Base configurations

esbuild

// package.json
{
"scripts" : {
    "build" : "esbuild src/index.ts --define:process.env.NODE_ENV=\\\"production\\\" --bundle --platform=node --outfile=lib/index.js"
    "postbuild" : "tsc --build"
    }
}

vite

This is a vite config for react and it has a few steps

// vite.config.ts
import path from 'path'

import { defineConfig } from 'vite'
import tsconfigPaths from 'vite-tsconfig-paths' // can remove if you don't use ts config paths

import reactRefresh from '@vitejs/plugin-react-refresh'

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [reactRefresh(), tsconfigPaths()],
  build: {
    lib: {
      entry: path.resolve(__dirname, 'src/index.ts'),
      name: 'packageName',
      fileName: 'index'
    },
    rollupOptions: {
      external: ['react'],
      output: {
        globals: {
          react: 'react'
        }
      }
    }
  }
})

```jsx
// package.json
{
"scripts" : {
        "build:tsc": "tsc --build && echo 'Completed typecheck!'",
    "build:vite": "vite build",
    "bundle:tsc": "node build/bundleDts.js",
    "build": "npm-run-all build:vite build:tsc  bundle:tsc",
}
}
```

For vite specifically we need to bundle all the `.d.ts` files into a single declaration file

```jsx
const dts = require('dts-bundle') // package that does this for us
const pkg = require('../package.json')
const path = require('path')

dts.bundle({
  name: pkg.name,
  main: 'dist/src/index.d.ts',
  out: path.resolve(__dirname, '../dist/index.d.ts')
})
```

tsup - is the easiest and just that tsup src/* --env.NODE_ENV production --dts-resolve

The only caveat is less configurable than esbuild itself

Packages that are meant to be deployed to support javascript

These packages all have to follow the build steps laid out above but this is something I wanted to explicitly address cause I did not see any other guide talk about this.

In development you want your packages to point to typescript, but in production you want to point to javascript + a type file. Unfortunately this is not natively supported by npm or npmjs (to the best of my knowledge), luckily here is where pnpm comes in clutch.

pnpm supports the following config, https://pnpm.io/package_json#publishconfig

// package.json
{
    "name": "foo",
    "version": "1.0.0",
    "main": "src/index.ts",
    "publishConfig": {
        "main": "lib/index.js",
        "typings": "lib/index.d.ts"
    }
}

// will be published as 
{
    "name": "foo",
    "version": "1.0.0",
    "main": "lib/index.js",
    "typings": "lib/index.d.ts"
}

The catch is you have to use pnpm publish if you use npm publish it will not work.

General things to note about publishing, you need access to public and the files you want to include

{
    "name": "@monorepo/package",
  "main": "src/index.ts",
  "license": "MIT",
  "browser": "dist/index.js", // can directly set browser to js
    "publishConfig": {
    "access": "public",
    "main": "dist/index.js",
    "typings": "dist/index.d.ts"
      },
      "files": [
        "dist/*"
      ]
}

You will likely have to use these broad categories together when in production, so feel free to mix and match.

Things I don't have good solutions for

Creating new package with a template, lerna has a cli thing for this but I couldn't seem to be able to configure it. (We use a hacky js script)
Versioning and publishing packages automatically, lerna had a thing for this too but it isn't great. When a single package goes to v0.1 not all packages have to go to v0.1

Would love to hear others solution to these and I can update this space with them

Conclusion

Unfortunately, monorepos are still kinda weird and complicated but I hope I gave you some of the tooling we use to make it easier. I also apologise if this felt a bit disorganized but it is a result of we came up with this structure with many many iterations and if we started new it probably would be a bit cleaner.

CryogenicPlanet / typescript-monorepo-example

Typescript monorepo example

Finally if you are at all interested in video or video editing come checkout modfy.video

You can also find the most upto date version of this post on https://cryogenicplanet.tech/posts/typescript-monorepo

Create Github Social Preview Images in a few clicks

Rahul Tarak — Fri, 23 Oct 2020 19:15:23 +0000

A problem I found when building public projects on github is creating social images to make it easier to share them on Twitter or reddit or even here.

Of course, there are solutions to this my favourite probably being canva, but it still can be a time sink to design these images to look good.

A few weeks ago Wei and I came up with a solution to fix this during MLH Fellowship

Wei HeFollow

( "👨‍💻 Full Stack Engineer" | "☁️ Solutions Architect Expert" | "💼 M.B.A." )

Presenting socialify

Socialify allows users to create beautiful preview images in three clicks.

Add your GitHub repo url
Choose your options
Download Image or Copy Image url

Image as a service

Socialify use the same concept of image as a service from Vercel's og-image

This allows users to have SVG images that automatically update badges and description overtime.

Some Example Images

Find our project

Website - https://socialify.git.ci/
Product Hunt - https://www.producthunt.com/posts/socialify

wei / socialify

💞 Socialify your project. 🌐 Share with the world!

Want your project to stand out? Socialify helps you showcase your project to the world by generating a beautiful project image like the one above!

It includes a ton of options including custom logo, description, badges, and many fonts and background patterns to choose from.

Join today!

Usage

Project site: https://socialify.git.ci

Social Image as a Service

Click on the image to use the link anywhere, the image will be programmatically generated with live data. This means the badges will automatically update.

Recommended for README files or img tags.

Image Download

You can download the image as a .png, .jpeg or .webp and use it anywhere in the world!

Recommended for GitHub repository social preview image and other sites that require image upload.

CLI

You can use cli tool mheap/github-social-image to upload social images to all your repos at once.

Examples

Development

Create a GitHub token from Settings > Developer…

View on GitHub

Oak Codefest 2019

Rahul Tarak — Fri, 07 Dec 2018 12:19:30 +0000

So I have been someone who has always loved computer science, I started writing code maybe when I was in 6th grade. I went to my first hackathon in 8th grade and it was one of the best experiences I ever had. Since then I have always noticed a lack of hackathons for high school students to encourage them to explore computer science.

I am very proud to say I am able to help solve this problem by bringing you Oak Codefest 2019, the is the second edition of this hackathon. It is Bangalore's first overnight high school hackathon and with just our first event we were able to inspire to other schools to follow suit and host hackathons.

This year for Codefest we want to make our event even bigger and have collaborated with IBM, DigitalOcean, Hackerearth and Ace Creative Learning.

To find out more details please visit http://codefest.oakridge.in