OSD600- Joey Assal

 To prepare for the issue I am planning on doing for release 0.4 I spent this week reading the code and learning how to view and test the login component I will port from gatsby to next! I first added the folders needed to the next/ directory and copied the LogIn component to next/components, this way everything will be organized while I do my work. One road bump was figuring out where and how to call the components for testing, but after careful study of the code, I learned how to do it. I then comment out the code in index.tsx  and called the login component. It didn't work! I realized that since I have not ported the component to next I will not be able to call it from the index.tsx. I have begun reading how to port components and already made some small modifications (eg. changing the hrefs). This week was dedicated to planning and understanding how everything works. I used to think that's not so important, but based on my past experiences I know this will pay off next wee

 This is it... the final lab of OSD600! The semester is almost over, and although I have really enjoyed this course and learned so much, I can't wait for the semester to end! Mainly because this is my last one then I graduate 🎓! This lab helps tie everything we did this semester by asking us to publish our link checker programs! since I wrote mine in Node I started looking into how to publish it to npm . I must admit, publishing to npm was not as hard as I thought it would be. This YouTube video really helped guide me. I also read the docs . However, there was one problem with all these resources. They did not show how to publish a command-line tool to npm. I understand I could have modified some of my code so the user can require() it, but it didn't make sense to me. I felt the user experience would be more enjoyable if they can install and use it as a command-line tool! I asked David about this and he told me about npx ! npx allows you to run modules from the terminal! This

 The semester is almost over and we have one more release! For  Release 0.4  we must top everything we have done before in the class! Sounds challenging but fun! I first read the assignment and saw the ideas our professor gave us. I decided I want to work on Telescope again. What drew me to Telescope was the community. They were all very nice, and I enjoyed working with them last time, so why not work with them again! I went on Slack and let them know I am interested in working on Telescope again, and asked if there is anything I can do. I was told to look at this pinned issue. They are currently porting GastbyJs code to Next.js code and can use some help porting the modules. I decided to do Login/, To be honest, I have no idea how to do this (although I haven't read any of the documentation provided yet) but I'm really not worried as I know there is a large community of people, and great resources to go to to help me accomplish this. Another great thing about this is I will le

Lab 8 involved writing tests for our link checker programs! Unlike other labs, this ran for two weeks and consisted of two parts! For the first part, we had to write some tests for our program, and for the second part, we needed to write some tests for another person's program. The testing framework I chose was jest . The two main reasons I chose this was because it's the most popular testing framework for Javascript, and I already had some experience working with it during release 0.3. Another tool I used was the npm module nock . This was so I can make mock requests to websites. Setting up both was pretty simple once I read the documentation. After installing jest make a test file. For example, if you wish to test functions in index.js make a file called index.test.js . To run the test run the command npm run test. Also, make sure in package.json   you add "test": "jest" in the "scripts" section. Nock doesn't require much setup besides requi

  For release 3 we have to make 2 PR's. The first one must be for the  Telesope project  and the second one must be for an external project. These PR's must "build up" from the PR's we did for release 0.2. This blog post will highlight working on the PR for Telescope. When I started this the first place I went was to the issues page on the Telescope repository. I saw there were some tests that needed to be written and were interested in taking on one of these issues. These were more complex than the test I wrote for the first part of 0.3 so  I saw it as a good opportunity to improve my skill. I asked in Slack for some advice on what to do and was given this idea from David: This seemed like a good test to write (challenging but something I can figure out) so I made an issue for it and started working! When I first wrote the test everything looked fine but it kept on failing. At first, I thought that's good, if we pass an invalid date shouldn't the test fa

 For this week's lab in my Open Source Development class, we looked at static Analysis tooling. The tools we needed to add to our link checkers were a source code formatter and linter . I decided to use Prettier  for my source code formatter and ESLint for my linter. Prettier is a formatter that helps make code more readable. One really useful feature it has is it allows you to "customize" how you want it to format your code by making a .prettier.rc file. For example in mine , I make sure every line ends with a semicolon, the padding width is 70 and I allow trailing commas. Prettier logo ESLint is is another static Analysis code tool for catching "silly" mistakes in JavaScript. It will raise an error and let you immediately if you did something wrong. This can also be helpful to enforce coding styles. Similar to Prettier it allows you to "customize" how you want it to check your code by making a .eslintrc.json file. For my code, I made sure every lin