For release 0.4 I decided to work on issue 1921 in Mozilla Thimble.
The issue was that the grunt task that runs when you run npm test only ran jshint. This doesn’t do enough style profiling. We needed to add eslint in order to catch style errors that contributors might miss.
I fixed this issue by first installing grunt-eslint. After that I needed to modify the Gruntfile.js file to include the eslint task. I included the files that should be checked by eslint when npm test runs.
Here is how the eslint task looks in the Gruntfile.js file:
In the .eslintrc.json file I added the rules that we needed to use. The only rule that I added was the indent rule. I specified that the indent of the files needed to be 2 spaces. I used the eslint indent rule to see how to turn the indent rule on and specify 2 spaces. Of course in the future many other rules can be added to this file as needed. All the eslint rules are available here: http://eslint.org/docs/rules/.
I also specified the ecmaVersion for the parser to be 6. I needed to include this in the .eslintrc.json file because if it is not there it will give many parsing errors like the keyword let is reserved and const is reserved.
Here is how the .eslintrc.json file looks:
My pull request is available here: https://github.com/mozilla/thimble.mozilla.org/pull/1971
In conclusion, I learnt that installing eslint for Mozilla Thimble was a similar process as how we installed eslint in lab 6. The difference here was that I needed to include the eslint task in the Gruntfile.js file. Using eslint in Mozilla Thimble will be very useful for future contributors since it checks their code style and warns if anything needs to be fixed. This can be especially useful for contributors that forget to use 2 spaces for indentation.
For release 0.3 I decided to work on issue 1908 on Mozilla Thimble.
The issue was updating major dependencies that Mozilla Thimble uses. The major dependencies that needed to be updated were:
I solved this issue by creating 9 separate pull requests for each dependency. This was suggested by @Pomax. This made it easy to debug and test each update rather than have one pull request that contained all the updates. I used npm-check to get a list of the major updates that were available for these dependencies. I found using npm-check was a great tool that made it really easy to get the updates and install them. It also updated the package.json file once the updates were installed.
After I updated each dependency separately I needed to test the update to see if everything works correctly. I did these steps for each of the updated dependencies in order to test them:
- npm install
- npm test
- vagrant up
- opened Thimble in localhost to test if everything is working
The update for grunt-lesslint resulted in having many warnings when running npm test. The warnings were from the rules known-properties and order-alphabetical. I needed to fix these warnings so that when npm test runs all the tests pass.
I fixed these warnings by turning off the known-properties and order-alphabetical rules in the Gruntfile.js file. This resulted in making the tests for lesslint pass since these rules were turned off.
For the grunt-cli update I needed to test it on bramble.mofostaging.net to make sure that nothing broke on staging from the new update. I tested it on staging and everything seemed to work fine.
As of now, most of these updated dependencies got merged in. However, some of them still need to be reviewed.
Here are my 9 pull requests:
In conclusion, I learnt that updating major dependencies resulted in sometimes needing to modify some files in order to meet with the new update. It is not as easy as just updating the dependency and expecting everything to work afterwards. Testings need to be made in order to check that everything is working properly. Also working on this issue made me become better with using Git since I needed to create 9 different branches for this issue.
This lab builds upon the previous lab. For this lab the task was to extend the previous lab’s code to include cloud PaaS deployment.
I needed to create a simple node.js web server and REST API that uses the Seneca module that was created in the previous labs. I than needed to deploy the server to run on the cloud hosting platform Heroku.
My GitHub repository is available here: https://github.com/badrmodoukh/Seneca2017LearningLab
My Heroku app URL is: https://protected-island-21203.herokuapp.com/
Steps I took to complete this lab:
I first created a node.js web server using express. This provided an HTTP based API for calling the Seneca module functions. I named the file server.js. This is the code in the file:
I than tested the server locally by running node server.js.
This enabled me to navigate to the routes I created which are:
After I tested locally and everything seemed to work properly I needed to deploy to Heroku. I install Heroku and was able to interact with it using the command line. I created a Procfile that informs Heroku which command to run when it starts the app.
After creating the Procfile I needed to add, commit, and push the code onto GitHub.
Once the code was on GitHub I than started the process of deploying the app onto Heroku. The commands I used to do this were:
- heroku create – this creates a new app and generates a random name for the app
- git push heroku master – this is used to push the code to the heroku remote that was created
- heroku ps:scale web=1 – this starts one web server with the code I pushed
- heroku open – this is used to open the app that was deployed to heroku
After doing these steps the app was running on Heroku.
Overall, doing this lab was quite interesting. I never used Heroku before and I found it fun and important learning how to use it. I liked the way Heroku works with Git making it easier to deploy code. I can see now why it is so important to run your code on cloud infrastructure like Heroku to test your work especially REST APIs. I will definitely consider using this in the future.