Suggest NPM packages to include in the Checkly Runtime

[tnolet]

We regularly release new Runtimes with updated NPM packages. We would love to hear which 3rd party NPM packages you rely on and are missing in our Runtime.

• How Runtimes work
• Current Runtimes and included packages

Please comment below with a package name you would love to see in our next Runtime!

[slmoore]

Hi @tnolet ! 2 npm package suggestions that would be helpful in the runtime, date-fns and react-localization, thanks!

[tnolet]

@slmoore We JUST released a beta of the new runtime! It includes data-fns. Here is the blurb we just posted on our community Slack.

---

Hey Folks, I’m excited to announce that we just released the beta version of our latest runtime, 2023.02! Here’s a quick overview of the main updates: Upgraded libraries:

• Playwright 1.32.1
• Faker 7.6.0 New additions:
• date-fns 2.29.3
• ws 8.13.0 Discontinued support for Mocha.

To try out the new runtime, simply enable it in the labs menu and start using it in your Checks.

[clementlize]

Hello, I would like to add luxon as a dependency. Below is the message I sent in the Slack to understand the context 😄

---

Hi there, I've been wondering if you were planning to add more dependencies in the future runtimes. I especially am very surprised that moment is still available but its new version luxon is not.

What I want to do: I wanted my test to have multiple behaviours based on the current time. For example, if it's currently between 10am and 1pm I'll check that div A is visible, and if it's between 5pm and 8pm I'll check that div B is visible.

The problem: I used the JS Date constructor new Date() in my code and then extracted the hour using Date.getHour(). I live in France, currently the timezone is UTC+02. When I run my check locally, it's fine but when I upload it and run it in Checkly, the hour value is what I expect minus 2 (because I guess your servers have a UTC local timezone).

My current solution: I saw that the moment library was available in the 2022.02 and 2022.10 runtimes, but moment does not support timezones! Well at least it's better than plain JS Date, so I found this function to extract the timezone offset and then pass it to moment. It works fine.

/**
 * From https://stackoverflow.com/a/68593283/8026386
 * @param timeZone 
 * @param date 
 * @returns 
 */
const getOffset = (timeZone, date) => {
    const utcDate = new Date(date.toLocaleString('fr-FR', { timeZone: 'UTC' }));
    const tzDate = new Date(date.toLocaleString('fr-FR', { timeZone }));
    return (tzDate.getTime() - utcDate.getTime()) / 6e4;
}

const date = moment().utcOffset(getOffset("Europe/Paris", new Date()));
const day = date.get("day");
const hour = date.get("hours");

What do I want? Moment developers themselves say that we shouldn't really use it anymore, and choose alternatives. See this blog post. They even created a better version, luxon. And it has exactly what I need to handle timezones. Here is the same code using luxon:

const date = luxon.DateTime.now().setZone("Europe/Paris");
const day = date.weekday;
const hour = date.hour;

So I would like you to integrate luxon in the dependencies :slightly_smiling_face: I don't really know what are the constraints about adding a new dependency, I'll let you tell me :smile: Thanks

[TaylorFacen]

I would love to see prisma included so that I can set up and tear down my data for browser checks more easily. For example, I might need to create a user with certain assets before completing a browser checks. Then, I would need to delete that user and their assets after the check.

[socluka]

There's a good solution to validating incoming email messages for gmail, that reduces the need for yet more third party apps in your testing stack: https://developers.google.com/gmail/api/quickstart/nodejs. This however requires @google-cloud/local-auth and googleapis in the npm runtime.

Is this something we might expect or is it too risky security-wise, since it requires our credentials stored in a json on your end?

Edit: Might be that only googleapis is required, and that local-auth is only required locally when initializing the credential files.