DEV Community: May

How to keep a healthy package.json

May — Sun, 08 Jan 2023 19:42:05 +0000

It is common for developers to add npm packages in their applications without knowing what is going on behind the curtains, while also following other bad package.json practices. It is understandable, most of us work in fast-paced environments where we have strict dates to deliver new functionality for our clients. However, as developers, we might face security concerns if we undermine the risk of adding a new npm package, and we should also at the same time keep a healthy package.json. In this article you will learn about the main concerns about npm package management and what we can do to avoid them.

1. Avoid trivial packages

A trivial package is a package that does functionality that a developer can easily code themselves. Trivial packages are common, a study found that trivial packages make up 16.8% of their studied npm packages. Trivial packages are used because they are perceived to be well tested implementations of code, however only 45.2% of trivial packages even have tests.

This data is concerning considering the risk one takes when adding a new package who can be exploited. One example where adding a trivial package went wrong is the left-pad package. On 22 March 2016 its creator, Azer Koçulu, decided to unpublish several of his packages in npm, including left-pad. This led to thousands of applications breaking - even high-profile applications like React, Babel and Node. This package consisted of roughly 11 lines of code.

Tip: When adding a new package to your project, analyze the cost-benefit and evaluate if you can develop the same functionality yourself without impacting the timeline of the project. Each new package is a new potential point of failure, so it is wise to minimize failures as much as possible.

2. Use SemVer

To keep a healthy package.json, first we need to take a look at Semantic Versioning, or SemVer. Below is a chart given by npm explaining how SemVer works:

Basically, we start our product release version with 1.0.0. Then, the next release version number depends on the type of changes that we introduce.

Tip: It's recommended to use caret (^) to accept minor and patch updates, and tilde (~) to accept patch releases only. Depending on your project's needs, you may use these restrictions to limit the version of the package your project will use. Check SemVer cheatsheet for more information.

If we follow SemVer, we can handle major updates manually which are more likely to break our code. If you're not sure if you're following SemVer ranges correctly check the SemVer calculator.

3. Avoid pinning dependencies

Pinned dependencies are packages which are fixed package versions. This is not recommended since the package will not get latest updates.

"dependencies": {
    "react": "16.8.6"
}

4. Avoid adding git repositories as packages

There is a way of adding git repositories as packages, but this should be mostly used as a last resort (for example, when the package doesn't exist in npm). If this repository is deleted or updated, you might face major issues.

"dependencies": {
    "react": "facebook/react"
}

5. Look up the package overall health

A package health can be defined by three questions:

- Is this package actively maintained?
- How many developers use it?
- Which are the known security issues?

All this information can be found in GitHub, you can also look at the npm weekly downloads of the particular package you have chosen to see how frequently it is used among the dev community. There is also the Snyk Advisor tool, which shows all this information in a very friendly UI: https://snyk.io/advisor/

Package management sounds a bit complex, and every team approaches it differently. I hope these points have given you an insight on the most important things to keep in mind to maintain a healthy package.json. There is no perfect way of handling it, but when we know the most common points of failure, we can avoid security risks and keep our application working.

In this article my goal was to give an overview of the most common tasks we can do to manage our npm packages, if you wish to go more in depth I recommend reading Karen De Graaf's article "Guide to managing npm packages in your package.json"

References:
Rabe Abdalkareem, Olivier Nourry, Sultan Wehaibi, Suhaib Mujahid, and Emad Shihab. 2017. Why do developers use trivial packages? an empirical case study on npm. In Proceedings of the 2017 11th Joint Meeting on Foundations of Software Engineering (ESEC/FSE 2017). Association for Computing Machinery, New York, NY, USA, 385–395. https://doi.org/10.1145/3106237.3106267

How one programmer broke the internet by deleting a tiny piece of code

How one developer just broke Node, Babel and thousands of projects in 11 lines of JavaScript

AWS Cloud Practitioner Journey - Resources

May — Fri, 09 Apr 2021 22:04:56 +0000

Cloud skills are becoming important in our roles as developers. One way to begin our path to learn about cloud computing is to take our first certification. The AWS Cloud Practitioner Certification is an optional step if you want to get an Associate or Specialty certification, but it's recommended since you get the exam experience while also validating your knowledge on the basics of AWS Cloud.

Here is the Cloud Practitioner Official Description. Notice it is recommended to have around six months of experience using AWS - but it's not necessary, you might need to dedicate around a week or two to be prepared for the exam.

What is important is actually getting experience practicing for the exam itself. My recommendation is to take a course covering all the contents of Cloud Practitioner certification and then get practice exams.

For courses I recommend these:

AWS Cloud Practitioner Essentials
This course is good for beginners and people with IT backgrounds as well. It gives explanations to every subject using videos and illustrations. At the end of each chapter you will be given a small quiz to test your knowledge.

Freecodecamp - AWS Certified Cloud Practitioner Training 2020
This course is a 4-hour in-depth video that covers everything you will encounter in the exam. It is less illustrative than AWS's training so I would recommend this video for people with an IT background and who need to cover the exam's content as soon as possible.

Choose the course you like the most, and then move on to the practice exams. In my case, I used this Udemy course to study for the certification.

In this course you are given 6 practice exams, you are able to take each exam as many times as you wish and you can review your correct/incorrect answers. Each question has detailed answer explanations, so it is recommended for you to review each incorrect answer on your practice exams so you can compare your previous knowledge and improve your score.

The first time I did the exams I scored about 68% in each one of them. Just review the exam's answers and why the answer you thought was right is incorrect. The next time you take any of these exams you will score around 85%-90% ;) and you will be ready for your certification.

I would say to do these exams every other day before your certification so you get an idea of which content you need to review.

While I strongly recommend getting the Udemy course, you can also check these free resources:
Official sample questions by AWS 10 example questions with answers
Youtube Practice Test This video is similar to the content you will get in Udemy tests, but mostly without explanations of the correct/incorrect answers.

I hope these resources can help you on your cloud journey! :) If you already got your certification, feel free to comment on any other resource you found useful to study from.

Design Patterns for Web Development

May — Tue, 03 Nov 2020 03:34:20 +0000

There are times where building a design structure for your project might seem daunting when you don't know how to start. Knowing design patterns can help us as developers to find out how to better build our software depending on how scalable we will want it or the kind of functionality we need.

Design patterns are typical solutions to common problems in software design. Rather than being a code solution, they are general concepts you can implement in your software to expect certain behavior from it. The book "Design Patterns: Elements of Reusable Object-Oriented Software", which has become a classic in software development, introduced 23 patterns to solve object-oriented design. Here I'm going to cover 3 design patterns which are some of the most used in front-end development.

But first, why learning design patterns is so important?

1.Recognize patterns in libraries and languages
Some libraries like Angular use design patterns in the way they are structured and the way they create solutions to problems. This gives us an idea of how we can use this current behavior to build our own solutions.

2.Avoid reinventing the wheel

It's easier to create solutions others have previously faced and succeeded in implementing them, than coming up with a solution from scratch.

3.Shared vocabulary

Within development teams, it's easier to talk about how to design your solutions if everyone in the team is familiarized with design patterns. It is easier to explain an abstract idea just by using its name rather than explaining the whole concept.

Types of Patterns

There are 3 types of design patterns depending on their behavior.

Creational patterns: Provide a structure to create objects easily, provide certain flexibility on its creation, and reuse existent code.
Structural patterns: Provide a structure that helps assemble objects and classes into larger structures.
Behavioral patterns: Assign responsibilities between objects and take care of communication.

Singleton

Singleton is a creational design pattern that restricts class to have only one instance, while also creating a global access point to this instance. It is used when control access to a shared resource is needed.

Use this pattern when you need to ensure control access to a resource that might return inconsistencies if it is changed by two different objects at the same time. (Ex. Databases, state of an object)

class Singleton {
    private static instance: Singleton;

    private constructor() { }

    public static getInstance(): Singleton {
        if (!Singleton.instance) {
            Singleton.instance = new Singleton();
        }

        return Singleton.instance;
    }
}

Observer

Observer is a behavioral design pattern in which objects get information about any events happening to the object they are observing. The observer pattern defines a subscriber method, which will update every object that is subscribed to itself, making sure every subscriber gets the latest update.

An example of an observer in our daily life would be subscribing to a newsletter. The moment you join the mailing list you are notified when there is a new publication.

Use this pattern when changes on one object may require updating other objects, and the actual set of objects is unknown or changes dynamically.

class Observable {

    // List of observers
    private observers: Observer[] = [];

    public attach(observer: Observer): void {
        const exists = this.observers.includes(observer);
        if (!exists) {
            this.observers.push(observer);
        }
    }

    public detach(observer: Observer): void {
        const observerIndex = this.observers.indexOf(observer);
        if (observerIndex !== -1) {
            this.observers.splice(observerIndex, 1);
        }
    }

    public notify(): void {
        for (const observer of this.observers) {
            observer.update(this);
        }
    }
}

class Observer {
    public update(observable: Observable): void {
        // Update observer according to Observable state
    }
}

Decorator

Decorator is a structural pattern that lets you add new characteristics to objects by adding a wrapper that contains the behaviors.

We can find examples of this pattern in food delivery apps where you can choose any toppings or extras to your food, then the application adds the corresponding cost to your order.

Use this pattern when it's necessary to add these extra behaviors on run time, or when inheritance is not possible.

interface Coffee {
    getCost(): int;
}

class SimpleCoffee implements Coffee {
    public getCost(): int {
        return 2;
    }
}

class CoffeeDecorator implements Coffee {
    protected decoratedCoffee: SimpleCoffee;

    constructor(decoratedCoffee: SimpleCoffee) {
        this.decoratedCoffee = decoratedComponent;
    }

    public getCost(): int {
        return this.component.getCost();
    }
}

class WithMilk extends CoffeeDecorator {
    public getCost(): int {
        return super.getCost + 0.5;
    }
}

Even though knowing these design patterns is useful to build better solutions, it is not always necessary to use them in every project we come across. We need to take some time to think about the pros and cons of implementing them on our own code. Remember to avoid overcomplicating your code if you will not get any benefit from using them in that particular case.

Have you used any other design patterns in your web development projects? Let me know which are the ones you use the most.

To learn more about design patterns check out:
Refractoring Guru - Design Patterns

7 Useful Features of Chrome DevTools

May — Sat, 25 Jul 2020 21:35:18 +0000

Preserve Log

Imagine you have a bug that causes a page to reload. Every time the bug gets triggered you lose all your logs and have no idea where to start debugging.

This function maintains a record of logs in the Console even after reloading. Go to Settings and then check "Preserve Logs" to activate it.

Tip: Run Clear console (Ctrl + L or Cmd + K) when you’re done debugging.

Debug on DOM Modifications

There are situations where you want to notice changes on a specific element to inspect what’s happening. To trigger a break when a DOM element changes, right-click on an element and then select one of the next:

Subtree modifications: Breaks when a script modifies the selected element’s children.

Attribute modifications: Breaks when an attribute is added to the selected element.

Node removal: Breaks when the selected element is removed.

Screenshots

Taking a screenshot using DevTools is quicker than opening an external application to capture your screen, especially when you can choose between capturing a selected area, full-size page, a specific node, or just your viewport.

Access this menu using Ctrl + Shift + P (or Cmd + Shift + P in Mac), then type “Screenshot” and select your desired option.

Reference a selected element in the Console

In the Elements tab, select an element you want to reference in the Console, then go back to the Console tab and type $0.

Show Rendering

It is helpful to look at what is rendering when we interact with our page, particularly when looking at performance issues. To highlight changes in the DOM we can go to Console, bring the tools bar using Ctrl + Shift + P (or Cmd + Shift + P in Mac) and then search for Show Rendering. Make sure to select the checkbox in the Rendering tab that activates Paint flashing.

Use Console Functions

Sometimes we could overuse console.log() to debug when there might be other useful functions for specific purposes inside the Console class.

For example, when logging an array of objects it can be useful to visualize this as a table. Use console.table() to visualize your data this way.

There are also different types of logs that we can use to prioritize issues like warning, error, and info.

You can then use the dropdown “Default levels” next to the filter box to filter between different types of logs.

copy(object)

This function allows you to copy anything into the clipboard. It is particularly useful when giving it a JSON object as it will copy a prettified version of your JSON into the clipboard.

You can also give this function an HTML element and it will copy it (and their children, if they do have any!)

DevTools has many other options that can help your productivity, for more information check out Chrome DevTools official documentation or Chrome DevTools Twitter account for new updates and tips.