GithubHelp home page GithubHelp logo

developersindia / website Goto Github PK

View Code? Open in Web Editor NEW
41.0 6.0 36.0 624 KB

๐Ÿ‡ฎ๐Ÿ‡ณ Website for The DevelopersIndia Community

Home Page: https://devsindia.netlify.app

License: MIT License

TypeScript 98.59% JavaScript 1.41%
nextjs community-project hacktoberfest

website's Introduction

CI/CD Pipeline GitHub commit activity GitHub Discord Subreddit subscribers

โ“ About The Project

The developersIndia community have grown exponentially & to commemorate such an achievement as well as to make our existence shown on the Internet we need a website! This repository will develop, track & maintain the said webpage.

โš™๏ธ Built With

We use the following set of technologies to build, design & host the website.

๐Ÿƒ Getting Started

If you would like to contribute to our webpage, the following section and instructions will help you get started right away!

To get a local copy up and running follow these simple example steps.

๐Ÿ“– Prerequisites

Ensure you've a Node.js runtime installed locally. It should also include a pre-packaged npm which can be install & setup a development environment for the project.

You would need to fork the project so that you can maintain you "private" copy of the project which you'll be pushing changes into. If you're confused on how to get started forking an existing project, refer to the official docs on "Fork a repo"

Once you've setup the prerequisites, proceed ahead with the installation procedures.

๐Ÿงฐ Installation

  1. Clone the forked repo. If you want to clone using SSH, run:

    # Replace the <GITHUB_USERNAME> portion with your GitHub username
    git clone [email protected]/<GITHUB_USERNAME>/website.git
  2. Change into the freshly cloned local repository & install the project dependencies.

    npm install
  3. Run the development server & check if the website is working as expected on localhost:3000

    npm run dev

For a more detailed guideline of contributing to the project, refer to the contributing guidelines for more information.

๐Ÿ“„ Licensing Terms & Conditions

The source code of the project is developed & maintained under a free & open-source license. Hence you're free to share, copy, modify the code as you deem it fit as long as you adhere to the terms & conditions of the MIT license. Hence for more information on the distribution guidelines, see the LICENSE document.

๐Ÿซ‚ Contributors

Thanks goes to these wonderful people (emoji key) for contributing to the project:


Avinash Maddikonda

๐Ÿ“–

Siddhant Kumar

๐Ÿ’ป ๐Ÿ‘€ ๐Ÿ“–

Gokul Viswanath

๐Ÿš‡

Ashish Kumar

๐Ÿ’ป ๐Ÿค” ๐Ÿ‘€

Somraj Saha

๐Ÿ’ป ๐Ÿค” ๐Ÿšง ๐Ÿง‘โ€๐Ÿซ ๐Ÿ‘€ ๐Ÿ“†

Omkar Kulkarni

๐Ÿ–‹ ๐ŸŽจ

Sushil Buragute

๐Ÿ–‹ ๐ŸŽจ

Samrendra Kumar Singh

๐Ÿ’ป

Bhupesh Varshney

๐Ÿ’ป ๐Ÿš‡ ๐Ÿ“– ๐Ÿ”ง ๐Ÿค” ๐Ÿ‘€

Himanshu Varshney

๐Ÿ’ป ๐Ÿš‡ ๐Ÿ“– ๐Ÿ”ง ๐Ÿค” ๐Ÿ‘€

Tarun Kishore

๐Ÿ’ป

Manav-SM

๐Ÿ’ป

Pushpender Saini

๐Ÿ’ป ๐Ÿ”ง ๐Ÿ‘€

vigneshwar

๐Ÿ’ป

Saurabh

๐Ÿ“–

Niketan Gulekar

๐Ÿ’ป ๐Ÿš‡

Devansh Bajaj

๐Ÿ’ป ๐ŸŽจ ๐Ÿค”

KRISHNA AR

๐ŸŽจ

Bhupesh Pradhan

๐Ÿ’ป ๐ŸŽจ

This project follows the all-contributors specification. Contributions of any kind welcome!

website's People

Contributors

allcontributors[bot] avatar bhupesh-v avatar bhupeshpr25 avatar dependabot[bot] avatar jarmos-san avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar

website's Issues

Create a custom icon for the featured text in the "Our Mission" section

Describe the nature & the intricate details of the enhancement of your suggestions.

Create a custom icon for the featured text in the "Our Mission" section of the website. Following is one such example:

Featured icon

More are available in the Figma template for reference.

Are you willing to take the initiative to implement & contribute a PR of the said feature/enhancement?

Yes

Will this enhancement require a significant code refactor or an increase in the total numer of lines of code in the source code?

Yes

Code of Conduct

  • I agree to follow the community's Code of Conduct

Add ESLint & Prettier support to keep a check on development standard practices.

The general public has general opinion on the best development practices all the time. Some prefers using double quotes over single quotes, while others prefer semi-colons after a line & others don't. Debates on such meaningless topics are unproductive, as such having a proper ESLint & Prettier configuration in place should keep a check on a standard development practice.

For reference on how to setup the configurations for each of those dependencies, refer to "Configuring ESLint" & "Prettier Configuration Options"

[BUG]: Fix & make the current CI/CD pipeline more robust

What happened?

Currently the CI/CD pipeline isn't only inefficient but it doesn't work as expected either. Following are the intended behaviour but for whatever reason it doesn't work:

  • Deploy to Netlify using GitHub Actions (causes an authentication issue even the auth tokens exists)
  • Make a comment on the PR with a preview URL

The expected behaviour is basically to deploy the static contents to Netlify after they've been generated on the GitHub Actions environment. Once the deployment is successful, comment on the PR with a preview URL.

Relevant log output

See https://github.com/developersIndia/website/runs/5703328348?check_suite_focus=true

Code of Conduct

  • I agree to follow this project's Code of Conduct

Develop a `ROADMAP.md` for the project

Feature details?

The project requires a public roadmap for better collaboration efforts. Having one such publicly facing documentation will help reduce redundant questions like the ones below from interested contributors:

  1. "Can I implement so & so feature to the website?!"
  2. "What's the plan? I can help, what should I contribute to?"
  3. "I've an amazing which is to add blah blah feature to the website! Can I add it to the website?"
  4. "The website isn't up yet! What's taking so long?! I could've completed working on it in mere # of days! Tell me what can I help you with?"

The list of such redundant questions are endless.

Having a public ROADMAP.md will help answer those redundant questions every now & then. On top of that, it'll also help interested contributors stay updated with:

  • What feature requests are accepted.
  • If there're any specific messages and/or events planned by the admin.
  • Have better foresight on the project's development & act accordingly without any distractions.

That said, if you would like to share your ideas & suggestions on how this project's roadmap should be like, then please check out the comments section of #69.

Code of Conduct

  • I agree to follow this project's Code of Conduct

Create a custom 404 page

Describe the nature & the intricate details of the enhancement of your suggestions.

Currently the project doesn't have a custom 404 page & it serves the default one created by Next.js. While it works but having a custom 404 page will improve the brand value of the website & the community in general.

Are you willing to take the initiative to implement & contribute a PR of the said feature/enhancement?

No

Will this enhancement require a significant code refactor or an increase in the total numer of lines of code in the source code?

Yes

Code of Conduct

  • I agree to follow the community's Code of Conduct

Issue tracker for the Footer section of the landing page

This thread tracks the enhancements, development & bug reports related to the CTA & Footer section of the landing page. Here's what they look like:

For more context on the overall project & what the landing page should look like, check out #133

The CTA:

CTA

The Footer:

Footer

Use the comment section to keep a track on the progress of the development of this section.

[FEATURE REQUEST]: Simplify `tsconfig.json` to make room for incremental changes when necessary

Feature details?

The current state of the tsconfig.json is too "strict" & it should be "toned down" to make room for future increments. On top of it, simplifying the config file will also get rid of errors caused by experimental features like #73.

That said, Next.js already provides a standard default config file with the following contents:

{
  "compilerOptions": {
    "target": "es5",
    "module": "esnext",
    "jsx": "preserve",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true,
    "lib": ["dom", "dom.iterable", "esnext"],
    "allowJs": true,
    "noEmit": true,
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "isolatedModules": true
  },
  "exclude": ["node_modules"],
  "include": ["next-env.d.ts", "**/*.ts", "**/*.tsx"]
}

The standard configurations should be a good starting point right now. Additionally, do take a look at the following config values which I think might benefit contributors with a better dev experience;

Add more of such config values I might've missed out & please have a productive discussion below before suggesting any additional config values.

Code of Conduct

  • I agree to follow this project's Code of Conduct

Add pre-commit hooks for better code quality control

Feature details?

Git hooks using frameworks like husky + lint-staged or pre-commit will ensure bad coding standards & practices aren't introduced to the source code. They'll cleaned & taken care of right at the source.

Further quality control can be ensured by implementing an automated CI/CD pipeline but for starters, Git hooks is the way to go.

Code of Conduct

  • I agree to follow this project's Code of Conduct

[BLOCKER]: Broken CI/CD Pipeline

What's the Issue

At the time of writing this thread, I've been attempting to battle this issue with our broken CI/CD pipeline's workflow. And so far it's been pretty much an uphill battle with GitHub's obscure documentations & unhelpful responses from GitHub's support team.

Regardless, here's what our ideal workflow would look like:

  1. Interested contributed share their PRs which should trigger a suite of workflows (which are supposed to perform a variety of tasks like code quality checks & what not).
  2. The first workflow to ALWAYS run is the "Code Quality Check" job which could include tasks like:
    • Running the test suite & ensure all tests pass sucessfully.
    • Running ESLint, Prettier & other tools to ensure the source code adheres to a standard practice.
    • Other related tasks should be included here.
  3. Once the "Code Quality Check" job passes successfully, it would trigger the workflow to run a "Build Website" job.
  4. Upon the "Build Website" job's success, the workflow would then deploy to Netlify with a "preview deployment URL".
  5. If the deployment was successful, the workflow would comment on the PR with a link to the "preview deployment URL".

Observations Made

So far, after multiple attempts at fixing the workflow, here are the following observations I made:

  1. GH doesn't allow access to the secret tokens to workflows triggered by PRs of forked repos. ๐Ÿ™‚
  2. The Netlify GH Action we're using works as expected (as is evident through #150).
  3. The documentation & the support team recommends using the pull_request_target event to trigger the workflow. The caveat while using this event is, the workflow will run in context to the base repo & not the contents of the PR. This means, the deployment URL willn't contain the changes as shared through the said PR (see #154).

Resources to Understand GitHub Action's Functionality

Possible Solutions to Fix the Issue

The only possible solutions I can think of on the top of my mind right now are:

  1. Perform a complete refactor of the pipeline to adhere to GH's security concerns by following this advice. Will it work? That remains to be experimented on, so contributions are welcome!
  2. Use a mix of both Netlify's CI/CD pipeline & GH Action for the various tasks. For example, perform code quality checks, run the test suite & such on GH Action. While Netlify would take care of the CI/CD needs on each PR. This path has a drawback, as in Netlify's 300 limited build minutes will be over in mere weeks if not days!
  3. If Netlify's limited build minutes isn't enough, then move to Vercel instead which offers a whooping 1000 build minutes (which is still nothing compared to GH's 2000 build minutes!).

Why're We Desperate to Stick With Gh Actions?

Every interested contributor I had a chat with about this issue had one thing to say:

Netlify takes care of X & Z, why bother using GH Action?

We use GH Action for one main simple reason which is to keep anything & everything related to CI/CD pipeline under a single roof. Other reasons include, Netlify's limited build minutes & inaccessible public logs in case something breaks during the build procedure.

Ending Words

If it's not already evident, I'm tired & frustrated spending my weekends fighting an uphill battle with GitHub. So, if you've any ideas, possible fixes, alternatives or any magical solution to fix our CI/CD pipeline, I'm all ears!

Please don't hesitate to reach out to me over Discord (Jarmos#8937) or heck even use the comment section below to communicate. Any positive contributions to this problem we're facing would be VERY appreciated right now.

[FEATURE REQUEST]: Add [Light/Dark/System Default] Theme support to the entire site from the beginning itself

Feature details?

As the title suggests, it would be easier and better to implement Light/Dark[/System Default] theme in the beginning itself, since the site is very small and still in its initial phase right now.

Example
:root,
:root[data-theme="light"] {
  --fg: #000000FF;
  --bg: #FFFFFFFF;
}

@media (prefers-color-scheme: dark) {
  :root {
    --fg: #FFFFFFFF;
    --bg: #000000FF;
  }
}

:root[data-theme="dark"] {
  --fg: #FFFFFFFF;
  --bg: #000000FF;
}

body {
  color: var(--fg);
  background-color: var(--bg);
}

Code of Conduct

  • I agree to follow this project's Code of Conduct

Implement a basic CI/CD pipeline to ensure code quality assurance.

Having a CI/CD pipeline in place will ensure all PRs & code pushed to the remote repository abides by standard coding practices. At some point in time the pipeline can also be extended to run an automated test suite and/or build-deploy the website after a series of checks. The checks might or mightn't contain:

  • Linting checks using ESLint
  • Formatting the source code by Prettier
  • Running the test suites
  • If all of the above passes build & deploy the website to production

The pipeline can made even more complicated if the need arises but to start with a minimal & basic template should be in-place. This issue will track the implementation of that basic CI/CD pipeline template.

Some quick housekeeping stuff that needs to be taken care of immediately

Feature details?

Overview

The project at it's current state is simple enough & hence is maintainable without any issues. But as the project grows certain issues that have slid without notice might create problems for later. For e.g; long running CI/CD pipelines, the same pipelines running out of build minutes quota & so on.

To-Do Tasks

Hence, this issue thread will track a couple of such housekeeping tasks that needs immediate attention. Please take a look at the following issues & let us know if you need any help when fixing them;

Justifications for the Above To-Do Tasks

Successfully closing the aforementioned issue threads will mean:

  1. The CI/CD pipeline is delegated to GitHub instead of Netlify which means status check logs will be publicly visible & under the same umbrella rather than elsewhere.
  2. Caching dependency downloads will improve the CI/CD pipelines by a minimum of 30% (approx) thus saving us some precious build minutes quota which can be used elsewhere!
  3. Having & fixing broken hyperlinks when they're found will save us from severe embarrassment (but do we even need something like that?).
  4. At it's current stage the workflows pass even if there's some ESLint or Prettier formatting issues. That behaviour is unintended & should be fixed at the earliest so that new PRs do not introduce subtle bugs & issues which are difficult to debug & identify.
  5. The project doesn't have any tests! ๐Ÿ˜ฌ Should I say anything more? Having a robust test suite in place will mean any new features and/or functionalities can be introduced to the project with confidence with utmost confidence.

NOTE: This thread will remain until all of the TODO tasks are complete. After that the thread will be closed & locked to prevent spam & clutter in the near future.

Code of Conduct

  • I agree to follow this project's Code of Conduct

[FEATURE REQUEST]: Configure Stale bot for the repository

Feature details?

Description of the Feature

Configure Stale bot for the project.

More Context

The bot should be configured to:

  1. Mark any Issue/PR threads which are older than 90 days to be marked with the stale label.
  2. Comment on the "stale" thread that it has another 30 days to receive some response before it's closed.
  3. Configure the bot to not mark threads labelled with the don't stale label as "stale".

Code of Conduct

  • I agree to follow this project's Code of Conduct

[BUG]: `next lint` doesn't work with staged files

What's the Concern

When running the pre-commit hooks on staged files, next run fails stating it can't find the pages directory (even though it exits). Screenshots attached for further context:

image
image

A possible solution to the issue could be provided in the documentations itself - https://nextjs.org/docs/basic-features/eslint#lint-staged. There's also a discussion with a similar report - vercel/next.js#30841

cc @DevanshBajaj who identified the issue.

Code of Conduct

  • I agree to follow this project's Code of Conduct

Develop a basic official developersIndia landing to start with

The developersIndia community requires an official website. Members of the community did work on it on & off for a while but none of the contributions led to any productive goals yet. As such we had a long discussion & decided to take baby steps.

The Plan Ahead

The immediate plan right now is to develop a VERY basic landing page with minimal aspects. In other words, features like dark mode or interactivity isn't a hard requirement right now. Developing an MVP which showcases our goals, who we're & how to be part of our community is all that's required for now. This is what we should be working towards for the "first iteration" of the project (more on it later on).

The Tech Stack

We're working against the clock & since most of us are busy outside work hours as well, this project is maintained completely on volunteer basis & as "a hobby project". Hence, the tech stack is kept minimal with ample room for further additions if necessary.

That said, after a thorough discussion, following is the current tech stack to be used for developing a minimal landing page:

  • Next.js for building the frontend UI/UX.
  • TypeScript for ease of maintenance & standard code quality assurance.
  • TailwindCSS + SASS to build & style custom components.
  • Vercel for deployment & hosting needs.

If you feel the project might benefit from using another tool or technology stack, please open an issue/discussion thread describing in details the benefits of it & some code samples of the implementation to go with.

How Can You Contribute to the Project

Contributions to the project inย ANY manner are ALWAYS appreciated. But if this is your first time contributing to FOSS projects, here are some ways we believe we could use your help:

  1. Got design skills and/or ideas? Please share your templates in this discussion thread.
  2. Find something missing or perhaps a typo here & there? Feel free to let us know about it or even better, report it through an issue thread & then reference it on a PR!
  3. Keep an eye out on the discussions going in various issue/discussion threads & chime in with your opinion & suggestions. In our community we're always favor member engagement over everything else. And it also brings us joy to see we could provide a meaningful platform for individuals to help one another out.

Please don't assume the points above are the only ways you can contribute to the project! If you need, feel free to reach out to us over DMs & we'll be happy to discuss the other ways you might want to contribute to out community efforts.

Ending Notes & Credits

Do note, we already have an amazing Figma template to use as a source of inspiration to develop the "first iteration" of the website. And by "first iteration", we mean the v1.x.x release of the project which you can track on the releases page.

This current issue thread will remain open for discussion & progress tracking until the v1.x.x is launched. After that the thread will be closed & locked for obvious reasons. As such if you would like share your ideas & templates for the minimal landing page of the website, please share it before the first public release of the website.

That said, we would like to thank @OmkarK45 & @sushilburagute for their contributions on designing the template we're using as a source of inspiration! Without their effort & contribution I doubt the project would've progressed as much as it did right now.

[FEATURE REQUEST]: Create a mobile-friendly template for the website

Feature details?

Thanks to the generous contributions of the two selfless contributors, we had a template to base the design of the website to work on! Unfortunately, due to lack of time, they couldn't design the mobile-friendly version of the template. As such, if you guys have design skills, please reach out to us or comment down below on how you would like to proceed.

For reference, please take a look at the template over here: https://www.figma.com/file/jxpIq8GzilqzgyLpFBySP2/Developers-India-%3C3?node-id=5%3A58734

Code of Conduct

  • I agree to follow this project's Code of Conduct

Project is missing an open-source license

What happened?

The project is missing an open-source license without which it can't be considered an open-source & community-maintained project in it's strictest sense. Hence, a license (preferably MIT to keep things simple) should be added to the project.

Code of Conduct

  • I agree to follow this project's Code of Conduct

Project release & version management draft

Feature details?

Overview

Every project requires a workflow for managing version & release management. This project is no exception to that fact either! There has been attempts to conceptualise what steps & procedures should be taken to setup a specific workflow for the project in #69. And the discussions made in that thread has been VERY productive as well.

Thanks to everyone who chipped in their two cents about developing the ROADMAP for the project, we now have a general overview of how to manage the project far into the future! But we need a more short term set of goals which individuals could look forward to for sharing their contributions. Hence, this thread will attempt to lay down the groundwork for managing a "release cadence" for the project.

How Often Should We Release

The nature of the project makes it difficult to maintain a fixed release schedule, hence, it's suggested to instead release a new version (or tag) when there are "important feature updates" to the project. The said "important feature updates" could be say;

  1. Developing the Hero section of the landing page.
  2. Adding a "info" section with information about the community.
  3. A new "About Us" tab in the navigation bar

....and so on.

Breaking down the end goal (figma template) into smaller components which should be developed individually will help manage public contributions more easily!

So, upon completion of each component, it would be advisable to perform a release. More about how each releases should be versioned & the procedure for releasing is detailed in the next few sections.

Versioning Rules

The project in question is a website & as such backwards compatibility isn't a requirement. Hence, straight off-the-bat, releasing versions of the project isn't possible using SemVer. As such we recommend following a different approach for versioning specific releases of the project.

Taking quite a lot of inspiration from this comment & the parent thread, it's suggested to follow a "Year-Month" versioning system. For more context, assuming the Hero section of the landing page was complete & a release could be made on the month of February & in the year 2022, then a tag aptly named v2022-02 could be released.

Nothing has yet been finalised yet so please feel free to share your suggestions on this regard.

Release Procedure

Before releasing a new version of the project, certain assumptions has to be made, checked & verified. In case some of those checklist items are missing or are out-of-place, please report it to the maintainers of the project beforehand.

That said, following are the assumptions that has to checked each time before making a release:

  1. Version numbers has been checked & updated as per the rules stated above in the "Versioning Rules" section. Also don't forget to the update the version entry in the package.json file of the project as well!
  2. Make an entry in a CHANGELOG.md file with the specific details of what's changed & in what version is it.
  3. All tests, linters, formatter & URL health checks pass both locally & in the CI/CD pipeline.
  4. Release specific milestones has been updated on GitHub, completed & cleared upon tagging a commit.

Once the aforementioned steps has been taken care of it's now suggested to tag a new version & performing a release on GitHub.

Final Words About the Workflow

The contents of the threads should be regarded as a source of inspiration only & nothing said here is set in stone. So, please keep that in mind & feel free to share your thoughts & opinion about "how should this project be maintained?". We welcome all sorts of contributions, discussions & opinion. And we'll gladly integrate them into the final draft of the documentations.

Code of Conduct

  • I agree to follow this project's Code of Conduct

Issue tracker for the Hero section of the landing page

This thread tracks the progress, feature enhancements & bug reports for the Hero section of the landing page. For an overview of what the final landing page is supposed to look like, take a look at #133.

That said, contrary to what's shared on the linked issue thread above, here's what the hero section of the final landing page should look like;

AlternativeHomePage

We believe this design & the aesthetics are more relatable to our community as such this is the template which we'll attempt to recreate.

For more context, here's what the hero section of the landing page should include;

  • A navbar with a logo & a few navigation links
  • The motto of the community in bold & as a header
  • The subheader of the motto which explains what out community is all about in as brief as possible.
  • Some quick navigation links to join our community (nothing about what it should be has been finalised yet, so please free to suggest in the comment section below).

And please use this thread to discuss anything & everything related to making progress on the hero section as designed in the image above.

[BUG]: `length` is declared here

What happened?

TypeScript complains about an issue like the screenshot below:

image

It could be caused by an upstream issue.

cc: @DevanshBajaj

What browsers are you seeing the problem on?

No response

Relevant log output

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

Optimise CI/CD pipeline by caching downloading dependencies properly

What's the Concern

The current CI/CD pipeline is inefficient & takes quite a while to complete it's tasks. Right now there's not much for the pipeline to do yet it takes a good min or two to simply perform code quality checks.

The main cause of this delay is the dependencies aren't cached & they are downloaded fresh for each run.

Possible Solutions to the Concern

Cache the dependencies properly by configuring the .github/workflows/main.yml workflow file. More information on how it can be achieved is available on "Caching dependencies to speed up workflows".

[FEATURE REQUEST]: Add CommitLint to standardize Git Commit message styling

Feature details?

What's the Concern

Interested contributors doesn't pay much heed to the commit messages at the moment. The messages doesn't describe what the issue was, what was done to resolve the issue (& perhaps an optional reference to the issue number). Having some set of tools and/or documentation in place will mean prospective contributors are obligated to pay attention to the clarity of the commit messages.

Following are some examples where the commit messages feel ambigious:

image
image

Possible Solution for the Concern

Use commitlint to enforce a standard practice of writing meaningful commit messages. Quite understandably, this isn't a proper solution & the contributor can still bypass the rules but hopefully having such tools in place will contain the ambiguity to an extent.

cc @Bhupesh-V let me know what do you think?

Code of Conduct

  • I agree to follow this project's Code of Conduct

Issue tracker for customising the theme of the website

Feature details?

Overview of the Thread

This thread will track the progress of customising the theme of the website. Use the comment section of this thread to:

  1. Keep a track on the development of the colour palette(s).
  2. To-Do tasks which are specifically related to the theme & it's customisation.
  3. Discuss possible bugs, feature enhancements & such (if related to the theme in any way).

TO-DO Tasks

Following are some pending tasks that needs to be taken care of eventually.

... more such TO-DOs will be added and/or updated as & when required

Code of Conduct

  • I agree to follow this project's Code of Conduct

Enable `fail-fast` to immediately fail the status checks on linter & formatting errors

What's the Concern

The current CI environment runs good but not well enough. It doesn't fail on lint & formatting issues which means prospective contributors can sneakily pass through non-standard coding practices. While each PR are reviewed thoroughly but an automated process is necessary to be efficient.

Hence, the current workflow configurations available at .github/workflows/main.yml should be refactored as required.

Possible Solution

Enable the fail-fast strategy in the workflow so that when a single job (say the linter or formatter job) fails, the whole workflow should immediately exit. This will save us a lot of build minutes, make the CI/CD more efficient & robust.

Resources for Reference

Update the contributing guidelines with more comprehensive details

Feature details?

#31 introduced a very minimal "contributing guidelines" template thanks to @siddhantk232. But the project requires a more thorough CONTRIBUTING.md which we can share with new contributors with confidence.

Having a detailed documented guidelines means we needn't:

  1. Ask contributors to follow certain standard coding practices.
  2. There will be no room for debate on certain aspects like the tech stack to choose from or certain standard coding practices.
  3. Having a written guideline of setting up a development environment and/or developing the project means development practices will be uniform & there will no room for issues like "but it worked on my machine!"

Code of Conduct

  • I agree to follow this project's Code of Conduct

Setup tests for the project

What's the Concern

The project doesn't have a single test written or configured yet! At it's current state the project is manageable & new features can be added without worrying about introducing some breaking changes. But once the project grows big enough, tests would be an absolute necessity by then.

So, it's good to get started writing & configuring the project with tests as quick as possible.

Possible Solutions

The Next.js official documentations suggests the following four frameworks for testing:

  • Cypress
  • Playwright
  • Jest + React Testing Library

...and it appears there's no clear "one solution for everything" when it comes to testing web app projects. So, if you've any ideas please share them over at #100.

cc @afkcodes if you've experience writing tests for frontend projects, could share some insights into how it's done?

[BUG]: ESLint in the CI/CD pipeline is broken

What happened?

#62 configured & added ESLint & Prettier support to the project but it also broke the CI/CD pipeline for some reason. Need to fix it somehow, see the failed workflows for reference.

Relevant log output

> [email protected] lint /home/runner/work/website/website
> next lint

Failed to load config "next/core-web-vitals" to extend from.
Referenced from: /home/runner/work/website/website/.eslintrc.json
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] lint: `next lint`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the [email protected] lint script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/runner/.npm/_logs/2022-02-06T15_09_39_051Z-debug.log
Error: Process completed with exit code 1.

Code of Conduct

  • I agree to follow this project's Code of Conduct

Draft a standard structuring convention for the React Components

Feature details?

Concerns Over Current Dev Practice

Since the project relies on Next.js, the concern about structuring files & directories for the project are pretty much covered as well! But Next.js doesn't provide any guidance on how to structure the many components a web app can have in it's lifetime. Yes, it's possible to dump all components under the src/components directory & call it a day but it can lead to a degree of ambiguity.

Suggestions for an Improved Dev Practice

As such I reviewed a couple of resources which suggested an improved standard structuring formulae for React projects. Following are the resources & their suggestions:

  1. "React Architecture: How to Structure and Organize a React Application" by Tania Rascia which suggests a directory structure for React SPA projects. The author advocates keeping everything related to a specific functionality in one single place. For e.g; keep all tests, style sheets & .tsx files under a one directory aptly named after that functionality. So, we could group Footer.tsx, Footer.test.ts, Footer.styles.css under the src/components/Footer directory.
  2. "How I set up a Next.js project structure" by Flavio Copes recommends a "page" components structuring. So, all components & it's related files used in the profile page should be placed under the src/components/Profile directory.

Ending Words

So, it appears there's no clear consensus on how exactly should components be structured but the aforementioned resources can definitely referred to as a source of inspiration. Keeping in mind scalability concerns & the scope of the project, I think we should pick the best of both the suggestions & build our own standards. Hence, this issue thread will keep track of drafting a standard practice of naming, structuring and/or any development practices of all the components used in the project.

That said, concerns, feedback and/or recommendations are very welcome! So please make the most out of the comment section below & share what you think.

Code of Conduct

  • I agree to follow this project's Code of Conduct

Share & document a colour palette to be used across the project

What's the Concern?

At it's current stage the project doesn't have a specific colour palette, interested contributors should refer to when customising the theme. Having a colour palette & one which is well documented will ensure all contributors adhere to a standard set of colours. And following such a standard will also ensure the branding of the website isn't cluttered & messed around with.

Possible Solution?

Solution is still under discussion & this section will be updated accordingly when a consensus is reached upon.

References

Following are some references you should follow to further understand how to standardise the colour palette of the project;

...more such resources are available on the official NextUI docs. And feel free to share more resources below if we missed out on something!

Issue tracker for the Info section of the landing page

This thread tracks the development, enhancement, bug reports of the info section of the final iteration of the landing page. For an overall description of what the final iteration of the landing page is supposed to look like, check out #133.

But this thread will be used to keep a track of individual developments on the Info section of the landing page. If you're not sure what does the Info section look like, here''re a couple images;

The Metrics Section (haven't confirmed what to include here yet):

Metrics section

The "Features" section:

Features section

NOTE: Since this section has the most number of sub-components please discuss what changes & enhancements do we need to make in this section before sharing a PR!

[BUG]: Builds fail on CI/CD

What happened?

Tailwindcss was removed in favor of NextUI, commit.

However, the imports are still present in styles/globals.css.

@tailwind base;
@tailwind components;
@tailwind utilities;

Along with that, postcss and its config and, tailwindcss config is still present, which again causes the issue.

module.exports = {
  plugins: {
    tailwindcss: {},
    autoprefixer: {},
  },
};

Which causes the CI/CD builds to fail

What browsers are you seeing the problem on?

No response

Relevant log output

Error: Cannot find module 'tailwindcss'

Import trace for requested module:
./src/styles/globals.css
./src/pages/_app.tsx

Code of Conduct

  • I agree to follow this project's Code of Conduct

Add `.ignore` files for Prettier & Eslint

Feature details?

ESLint & Prettier are well supported in the project & is configured really well. But right now, there's chance the configured linter & formatter might make perform certain unwanted actions on areas which shouldn't be changed in the first place! Once such place are the files under node_modules which should be ignored.

So, identify other such files or directories which should be ignored by ESLint & Prettier to be added to their respective .ignore files. Refer to the following documentations for more info:

  1. .eslintignore for ESLint.
  2. .prettierignore for Prettier.

Code of Conduct

  • I agree to follow this project's Code of Conduct

Perform "health checks" on the project URLs to see there're no broken hyperlinks

What's the Concern

Quite often URLs are either taken down or break down for whatever reasons. And web pages referring to those URLs are totally unaware of the issue until some good Samaritan out there reports it. But embarrassingly enough, these broken hyperlinks stay in the document without ever being reported most of the time.

As such, there should be scheduled URL health checks to identify if the website hyperlinks to any dead URLs or not.

Possible Solutions

None that I know of except our own @Bhupesh-V's AreYouOk project. So, if you know of any such project and/or how should such an project be integrated into the current project then feel free to share your ideas below.

cc: @yashsharan0805 @manav-sm @afkcodes

Breaking down the "landing page" Figma template into smaller components for easier asynchronous collaborations

Feature details?

Overview

Successor to #20 this TODO thread will keep track of each individual components of the website that should be developed asynchronously. Completing each individual tasks in this thread will mean we can close & lock it's successor thread with confidence.

The final iteration of the website will more or so look somewhat like the following image (see individual issue trackers shared below for further instructions on what specific changes needs to be made);

Main Page

The whole landing page is broken down into multiple smaller components which will make it easier to code, review & manage the project. For example, the Hero section can be one individual component with it's own issue tracker. This single component can have other features of the website like the navbar, responsive design support among other stuff. And all these sub-components can be tracked under their own tracker.

The rest of the page can also be broken down into it's own individual components like the Info & Footer section. Each of those components can have it's own set of sub-components.

Tasks to Complete

Following are the separate threads which will be used to keep a track of the individual components of the landing page;

Code of Conduct

  • I agree to follow this project's Code of Conduct

Develop & share a "proper" public roadmap

Feature details?

There's a template to work with, there are ideas & there are interested contributors willing to provide a helping hand to the project. What's missing is a "solid & proper" public roadmap to help the community work towards a common goal.

So, if you've ideas and/or experience on developing a roadmap for web-based applications, please feel free to discuss it here. You can share ideas, resources and/or suggestions below in the comment thread.

cc @siddhantk232

Code of Conduct

  • I agree to follow this project's Code of Conduct

[FEATURE REQUEST]: Write clause about adding yourself as a contributor to the contribution guidelines

Feature details?

It's difficult to keep track of all contributors who shares a PR or two, hence it would be best to let the contributors know about using the All Contributors bot. As such, if there's ever a case where the maintainers forgets to add a contributor to this list, then that contributor should be able to add themselves to it as well.

That way it should also reduce potential spam & clutter by closing issue threads like #51.

Code of Conduct

  • I agree to follow this project's Code of Conduct

[FEATURE REQUEST]: Containerising the project

Feature details?

I think it's good to containerise the project from the start and let the developers work on top of it. It will also be useful and hassle-free for new contributors. Instead of telling them to install node and related libraries, we can tell them to just install docker. Once they have docker installed, they can run/stop the project with simple one liners like docker-compose up/down. I think it provides a nice abstraction layer and as we can also have live reloading, this transition should be seamless.

Code of Conduct

  • I agree to follow this project's Code of Conduct

Refactor & clean up code base to restart the project

@sidharthgehlot had started the project a while ago but got occupied with work midway, since then we've decided to restart the project right now.

For starters, the code base requires a thorough cleaning & refactoring before work on developing the minimal landing page (refer to #20) can start. There's already an open PR #13 which hasn't been updated in a while so that needs to be taken care of before it can be merged.

Doing this is a necessity if maintainability & scalability is a requirement.

TO-DO:

  • Create & move the necessary files/folders into a src directory (refer to next.js src directory for more info). (see #24)
  • Remove unnecessary packages & dependencies which aren't required to build a minimal landing page. (see #23)
  • #25
  • Add .editorconfig & .gitattributes files for better cross-platform development practices. (see #24)
  • #26
  • #27
  • #28

This thread will be updated (or reopened) if necessary until the first iteration of the minimal landing page is deployed.

Add basic config files like .editorconfig for better collaboration efforts

Collaboration on any software development projects requires everyone collaborating on the project to have somewhat of the same development experience as one another. As such, it's necessary to have configuration files like .editorconfig, .gitattributes files & such to be added to the repository.

That said, following are the list of such files/folders which needs to updated and/or added:

  • .editorconfig (see #24)
  • .gitattributes (see #24)
  • #41
  • And updated README.md (see #37)
  • A tsconfig.json file since the project will be developed using TypeScript. (see #30)

More such configuration files will added to the list as required.

[BUG]: Giving credits to the non-source code contributors

What happened?

All Contributors might've missed out the following people:

Credited? GitHub Profiles Their Contributions
โœ”๏ธ Omkar Kulkarni Co-designed the website template
โœ”๏ธ Sushil Buragute Co-designed the website template
โŒ Bhupesh Varshney Co-maintainer of community & all community projects
โŒ Himanshu Varshney Co-maintainer of community & all community projects

Is it possible to add these people to the list of contributors as well?

Also let's keep this issue thread open till we release the first iteration of the website. We can use it to track people whose credits are due.

cc @Bhupesh-V

Code of Conduct

  • I agree to follow this project's Code of Conduct

Modify present GitHub Actions workflow to deploy to Netlify

What's the Issue?

The current GitHub Action does nothing more than run ESLint & Prettier to check for common coding styles. As such, it simply standardizes those differences within a CI environment. As for the CD part, that's taken care off of by the Netlify which results in some redundancy.

Netlify's free tier also provides measly 300 build minutes per month which isn't enough for an opensource project to be honest. Hence, we need to delegated the every aspect of the CI/CD pipeline over to GitHub instead. Since GitHub provides a generous 2000 build minutes a month, we won't be running out of it any time soon. And not to forget it's easier for contributors to debug CI/CD issues when the infrastructure is in the same place.

Possible Solution to the Issue

Possible solution to the issue to simply add another job to the current workflow which is configured at .github/workflows/main.yml.

There quite a few community built GitHub Actions out there to deploy to Netlify & following is an example I picked up from one of those Actions:

     # Rest of the workflow contents
      - name: Deploy to Netlify
        uses: nwtgck/[email protected]
        with:
          publish-dir: './dist'
          production-branch: master
          github-token: ${{ secrets.GITHUB_TOKEN }}
          deploy-message: "Deploy from GitHub Actions"
          enable-pull-request-comment: false
          enable-commit-comment: true
          overwrites-pull-request-comment: true
        env:
          NETLIFY_AUTH_TOKEN: ${{ secrets.NETLIFY_AUTH_TOKEN }}
          NETLIFY_SITE_ID: ${{ secrets.NETLIFY_SITE_ID }}
        timeout-minutes: 1

Resources for Referral

Following are some resources for referral which should help in configuring the workflow further:

[BUG]: `npm run build` fails due to a Type Error

What happened?

When trying to build a production build with the command npm run build on my system
it fails with the error

Type error: Option 'emitDecoratorMetadata' cannot be specified without specifying option 'experimentalDecorators'.

[ScreenShot]
image

Possible fix that i found

  • Adding the option "experimentalDecorators":true in tsconfig.json fixes this issue

After above fix
[ScreenShot]
image

You can assign me this issue and i will send a PR with the fix

My System
npm [8.4.1]
node [v17.3.0]

What browsers are you seeing the problem on?

Firefox

Relevant log output

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

Add a basic `tsconfig.json` for full TypeScript support in the project.

TypeScript not only provides "type safety" for JavaScript code but in general helps maintaining standard development practices in a project. As such, right now is the best opportunity to add TypeScript support for the project since it can be quite difficult to get started up again later on when the project is moving ahead already.

For more reference on setting up a proper tsconfig.json file, refer to it's official documentations: https://www.typescriptlang.org/tsconfig

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.