DEV Community: Reece Daniels

app.cacher.io

Reece Daniels — Thu, 28 Mar 2024 21:35:29 +0000

I'm a big fan of this app.

Whilst Copilot (another great app) is there to help predict what you might want to write, app.cacher.io is there to help you remember the things you've done before.

It's got a great VSCode extension that let's you search for existing snippets at the drop of a hat and also allows you to save new snippets directly from VSCode.

Well worth the $6 per month.

Why Your npm link Commands Might Be Failing

Reece Daniels — Tue, 31 Mar 2020 11:43:00 +0000

Problem

Summary

When you try to use npm link to install a dependency you’re working on locally, the changes aren’t reflected in your project.

You also see intermittent issues starting your project (esp. in TypeScript), as well as subdependencies not resolving correctly.

Solution

Summary

There are two issues you can run into when npm link isn’t working which are worth noting;

nvm related issues
Peer Dependency related issues

nvm

nvm, or Node Version Manager, is a tool used to run different versions of node locally across microservices at the same time.

When running npm link, the specific version of node being used in the project will be used to create the link, which means only projects using the same version of node will be able to access the local version of the dependency. This can be all the more frustrating because npm link doesn’t throw an error when this happens.

Here’s the readout when using different versions of node (one using 8.9.4, the other using 12.13.1):



/Users/myName/dev/_github/myRepo/node_modules/myDependency ->
/Users/myName/.nvm/versions/node/v12.13.1/lib/node_modules/myDependency

And here’s the readout with the same version of node (both using 8.9.4):



/Users/myName/dev/_github/myRepo/node_modules/myDependency ->
/Users/myName/.nvm/versions/node/v8.9.4/lib/node_modules/myDependency ->
/Users/myName/dev/_github/myDependency

Notice how the bottom line resolves to a folder where the dependency resides locally.

To fix this, use node -v in each project and check the running version of node. Use nvm install x.x.x & nvm use x.x.x to match them up.

Afterward, delete your node_modules, delete your package-lock.json, re-run npm i, and re-run npm link in your dependency folder and npm link myDependency in your project folder.

That should help.

Peer Dependencies

If your dependency has references to peerDependencies in it’s package.json you could stumble into issues with symlinks. These manifest themselves in the form of the peerDependency being unablee to be resolved at either compile time or at run time when needed.

The fix for this relatively simple. Add --preserve-symlinks into your start script e.g. node --preserve-symlinks build.

This will instruct your startup script to look in the correct place for it’s peer dependencies when running locally. Note that you’ll want to remove the flag once you’re done testing locally.

Problem (Hopefully) Solved

If you have any questions you’d like to ask me about this post, feel free to reach me on Twitter or Github.

Creating Interfaces From Joi Schemas In TypeScript

Reece Daniels — Sat, 14 Mar 2020 11:43:00 +0000

Problem

Summary

Using joi inside a Typescript project means you need to create two validation schemas, one for Joi at runtime and one for Typescript at compile time.

This causes you issues with maintainability, consistency, and violates the DRY principle.

Code Example



import * as joi from '@hapi/joi';

// Ignore the technical arguments of these schemas - purely for example purposes
interface UserAddress = {
  // etc..
  postCode: string;
  startDate: string;
  endDate: string;
}

interface User = {
  name: string;
  phoneNumber?: number;
  addresses: UserAddress[]
}

const userAddress = joi.object({
  // etc...
  postCode: joi.string().required()
  startDate: joi.date().required(),
  endDate: joi.date().required()
})

const user = joi.object(({
  name: joi.string().required(),
  phoneNumber: joi.number().optional(),
  addresses: joi.array().items(userAddress).required(),
}))

Solution

Summary

Use joi-extract-type.

An NPM package that is surprisingly underused (currently only 4,300 downloads per week on NPM) give it’s support for complex joi schemas.

There are two issues that should be noted as of writing this; one technical, one aesthetic

It has trouble managing the .unknown joi method at the object level (which declares that unknown keys are allowed on an object). Looking through the joi-extract-type code, it appears the method isn’t catered for.
You lose the pretty TypeScript interface look and feel - with a lot of your code now rendered in the standard JavaScript object colouring (theme dependant of course).

Code Example



import * as joi from '@hapi/joi';
import 'joi-extract-type'

const userAddress = joi.object({
  // etc...
  postCode: joi.string().required()
  startDate: joi.date().required(),
  endDate: joi.date().required()
})

const user = joi.object(({
  name: joi.string().required(),
  phoneNumber: joi.number().optional(),
  addresses: joi.array().items(userAddress).required(),
}))

export type User = joi.extractType<typeof user>;
export type UserAddress = joi.extractType<typeof userAddress>;

User & UserAddress will work equivalent to traditionally declared User & UserAddress interfaces.

You’ll also need to make sure the version of joi-extract-type that’s being used is aligned with the correct version of joi.

@hapi/joi@17 & joi-extract-type@15.0.2 seem to work fine together.

Problem Solved

If you have any questions you’d like to ask me about this post, feel free to reach me on Twitter or Github.

Using Cookies, Puppeteer & NodeJS To Mirror A Chrome Profile on macOS

Reece Daniels — Mon, 10 Jun 2019 10:00:00 +0000

Mirroring the state of one of your existing Chrome Profiles in Puppeteer can prove extremely useful for local projects and testing.

Unless you’re interested in simulating an entire login process, utilising pre-existing settings - in this case, cookies - can significantly reduce your time spent replicating a state that exists elsewhere on your machine.

The following process requires NodeJS, NPM and Puppeteer. You’ll need to install all of those items in that order before going any further. Follow the instructions on their respective websites to get them installed on your system

The first issue is accessing the cookies. Cookies are encrypted for good reason: they contain sensitive information. On macOS, they’re ‘signed’ with a Chrome encryption key into an SQLite database which is managed by the OS keychain. In order to decrypt the signed cookies, your Node application must have access to the Chrome key inside the keychain. This requires authorisation by the logged in macOS user.

Thankfully, there is an NPM module chrome-cookies-secure that is setup to handle this process. Copy and run the following code in your terminal (in the root of your project directory) to add the chrome-cookies-secure module to your project:

npm i --save chrome-cookies-secure

If you’re not prompted to authorise Node access to your keychain on the module install, don’t worry. You will be prompted when you run the basic NodeJS app described a little further down.

Next you’ll need to identify the path to the Chrome Profile you want to mirror (you may have multiple you’d like to choose from).

Open Chrome and make sure you’re browsing with the profile you want to retrieve the cookies for, and navigate to chrome://version. You’ll find the Profile of the current browser session under Profile Path.

You can view all of your Chrome Profile directories at Users/yourName/Library/Application Support/Google/Chrome.

This is often written as ~/Library/Application Support/Google/Chrome where ~ refers to the user’s root directory (In Finder Macintosh HD > Users > userName = ~).

Now you have the basic information you need to retrieve your cookies within your Node app! Below is a simple code snippet to demonstrate the functionality. Let’s take a look at our https://www.google.com cookies.

In a file of your choosing inside your project folder (I’ve called mine server.js) paste in the following code:

const chrome = require('chrome-cookies-secure');

const url = 'https://www.google.com';

chrome.getCookies(url, 'puppeteer', function(err, cookies) {
    if (err) {
        console.log(err, 'error');
        return
    }
    // do stuff here...
    console.log(cookies, 'cookies');
}, 'yourProfile') // e.g. 'Profile 2'

The module does not yet fully support Promises or async/await, but we’re looking to add support. You can help us add it in at https://github.com/bertrandom/chrome-cookies-secureUpdate! March 2020 - there is a PR for a Promise wrapper awaiting approval - https://github.com/bertrandom/chrome-cookies-secure/pull/21

Next, ensuring you’re in the project root directory in your terminal, run node yourfilename.js. You should see the cookies for the given profile and url you have chosen appear right there in the terminal, e.g:

In this example, we are looking at Google’s cookies. In the next section you will want to change this to a website where you are currently logged in

Now you can see your cookies in NodeJS, you can load them into Puppeteer!

Update your code to the following and run node yourfilename.js.

const chrome = require('chrome-cookies-secure');
const puppeteer = require('puppeteer');

const url = 'https://www.yoururl.com';

const getCookies = (callback) => {
    chrome.getCookies(url, 'puppeteer', function(err, cookies) {
        if (err) {
            console.log(err, 'error');
            return
        }
        console.log(cookies, 'cookies');
        callback(cookies);
    }, 'yourProfile') // e.g. 'Profile 2'
}

getCookies(async (cookies) => {
    const browser = await puppeteer.launch({
        headless: false
    });
    const page = await browser.newPage();

    await page.setCookie(...cookies);
    await page.goto(url);
    await page.waitFor(1000);
    browser.close()
});

You’ll see Puppeteer open and navigate to your chosen site, and hopefully, providing there are no further security measures such as 2FA, you’ll see that you are logged in!

It’s worth noting there can be a thirty minute delay between new cookies in your Chrome Profile being reflected on your hard-drive (thus being accessible in your Node app). This is because Chrome persists cookies to storage once every thirty minutes. So if you have new cookies, give it 30 minutes and check it again.

You’ll also need to fully qualify URLs in order to retrieve all possible cookies for a given site i.e https://www.google.com not https://google.com.

But that’s it!

You should now be able to do what you want to do with Puppeteer, utilising a login state, preferences, or whatever else, from one of your Chrome Profiles!

GoDaddy, Surge, Apex Domains & CNAME Records

Reece Daniels — Tue, 28 May 2019 10:00:00 +0000

Problem

Summary

You need to get an apex domain (https://yoursite.com) you purchased at GoDaddy resolving correctly.

Explanation

The problem you face if your asked to do this is that - for basic domain purchases at least - GoDaddy doesn’t let you add CNAME records for apex domains .

An apex domain refers to https://yoursite.com rather than https://www.yoursite.com.

Solution

Explanation

The advice from GoDaddy is that you must delete all A & CNAME records on GoDaddy first before adding any other CNAME or A records.
You must replace the CNAME @ record with an A @ record using the IP of your host provider.

My host is surge.sh, who provide their IP in this documentation.

Thus, to have my domain recognised when deploying to surge I needed to delete all existing A & CNAME records, and to add the following two records following in the Type : Name : Value format:

CNAME: www : na-west1.surge.sh

A : @ : 45.55.110.124

Once complete, my domain resolved within 5 minutes.

If you’re struggling to locate your providers IP, try messaging them on Twitter or searching StackOverflow, but once you have it, it should do the trick.

Original source: GoDaddy Forums