23 posts tagged with "Node.js"

The npx command is a powerful tool for running CLI tools shipped as npm packages, without having to install them globally. npx is typically used to run packages on the public npm registry. However, if you have a private npm feed, you can also use npx to run packages available on that feed.

Azure Artifacts is a feature of Azure DevOps that supports publishing npm packages to a feed for consumption. (You might want to read this guide on publishing npm packages to Azure Artifacts.) By combining npx and Azure Artifacts, you can deliver your CLI tool to consumers in a way that's easy to use and secure.

This post shows how to use npx and Azure Artifacts to deliver your private CLI tool to consumers.

Azure DevOps has a feature called Azure Artifacts that supports publishing npm packages to a feed for consumption. Publishing a private npm package with Azure DevOps is a common scenario for teams that want to share code across projects or organizations. This post shows how to publish a private npm package with Azure DevOps.

Publishing a private npm package with Azure DevOps is fairly straightforward, but surprisingly documentation is a little sparse.

Azure DevOps has a feature called Azure Artifacts that supports publishing npm packages to a feed for consumption. Typically those npm packages are intended to be consumed by a restricted audience. To install a package published to a private feed you need to configure authentication, and for non Windows users this is a convoluted process.

azdo-npm-auth exists to ease the setting up of local authentication to Azure DevOps npm feeds, particularly for non Windows users.

When I attempted to set the column of a User Story in Azure DevOps using the Azure DevOps Client for Node.js, I was surprised to find that the field System.BoardColumn was read-only and I bumped into the error:

TF401326: Invalid field status 'ReadOnly' for field 'System.BoardColumn'.

This post explains how to set the column of a User Story in Azure DevOps using the Azure DevOps Client for Node.js and it's based in part on a Stack Overflow question.

I often use the Azure Static Web Apps CLI for local development. It's not only handy when building Azure Static Web Apps, but also when building other types of web app, which also rely upon both a frontend server and some kind of API server. The Azure Static Web Apps CLI is particularly handy if you want to spoof authentication / authorization as well.

Changes in the behaviour of Node.js in version 17 caused issues with the Static Web Apps CLI. You can read a previous post which discussed this. However, whilst the issue was fixed in version 1.1.4 of the Static Web Apps CLI, it caused significant performance regressions in the CLIs dev server functionality.

This post shows you how to improve your developer experience by using Vite server proxy instead.

I love using .env files to configure my applications. They're a great way to keep configuration in one place and to keep it out of the codebase. They're also a great way to keep secrets out of the codebase.

But what if you need to use a multiline string in a .env file? How do you do that? You just do it:

SINGLE_LINE="you know what..."
MULTI_LINE="you know what you did
LAST SUMMER"

That's right, you just use a newline character. It's that simple. Oddly, searching for that on the internet didn't yield the answer I was looking for. So I'm writing it down here for posterity.

With your .env file in place, you can then consume it in your application using a package like dotenv. Or if you'd like to use a bash script to consume the .env file, you can do it like this:

#!/usr/bin/env bash
set -a
source test.env
set +a

npm run start # or whatever you need to do

I make use of Azure Static Web Apps a lot. I recently upgraded to Node.js 18 and found that the Static Web Apps CLI no longer worked when trying to run locally; the API would not connect when running swa start:

[swa] ❌ Could not connect to "http://localhost:7071/". Is the server up and running?

This post shares a workaround. This works for v1.1.3 or earlier of the Static Web Apps CLI. If you're using v1.1.4 or later, you should not need this workaround. But in that case you might find this post helpful on improving performance with 1.1.4 or later.

I've wanted to take a look at some of the alternative JavaScript runtimes for a while. The thing that has held me back is npm compatibility. I want to be able to run my code in a runtime that isn't Node.js and still be able to use npm packages. I've been using ts-node for a long time now; it's what I reach for when I'm building any kind of console app. In this post I want to port a console app from ts-node to Bun and see how easy it is.

Node.js 18 doesn't allow legacy TLS renegotion by default. But some APIs still need it. Also, corporate network traffic network is often subject to SSL inspection and that can manifest as a downgrade in TLS negotiation. Palo Alto Networks SSL Inbound Inspection is an example of an SSL inspector that can downgrade TLS.

This post shows how to support work around this issue with Axios.

Support for Node.js 16 for Azure Pipelines custom pipelines task extensions has arrived. From a TypeScript perspective, this post documents how to migrate from a Node.js 10 custom task to one that runs on Node 16 using azure-pipelines-task-lib.

Updated 26th September 2024 - Node.js 20 support available​

It's now possible to use Node.js 20 in tasks! See more details below:

• https://aka.ms/node-runner-guidance
• There is a guide on how to migrate tasks to Node.js 20 here

What's more we're going to start to see warnings emitted in pipelines when an EOL Node version is used.

This post demonstrates enriching an XML sitemap with lastmod timestamps based on git commits. The sitemap being enriched in this post was generated automatically by Docusaurus. The techniques used are predicated on the way Docusaurus works; in that it is file based. You could easily use this technique for another file based website solution; but you would need tweaks to target the relevant files you would use to drive your lastmod.

If you're interested in applying the same technique to your RSS / Atom / JSON feeds in Docusaurus, you may find this post interesting.

This post demonstrates reading and writing XML in Node.js using fast-xml-parser. We'll use the Docusauruses XML sitemap as an example.

Azure Static Web Apps presently fixes to Node.js 14 when building. If you require a different version of Node to build, this can be a problem. This post outlines a workaround.

Builds can be made faster using tools like esbuild. However, if you're invested in webpack but would still like to take advantage of speedier builds, there is a way. This post takes us through using esbuild alongside webpack using esbuild-loader.

The Azure DevOps Client library for Node.js has limitations and missing features, IGitApi.getRefs is missing pagination and IWikiApi is missing page create or update. This post details some of these issues and illustrates a workaround using the Azure DevOps REST API.

Yarn PnP is an innovation by the Yarn team designed to speed up module resolution by node. To quote the (excellent) docs:

I'd been meaning to automate the npm publishing of ts-loader for the longest time. I had attempted to use Travis to do this in the same way as fork-ts-checker-webpack-plugin. Alas using secure environment variables in Travis has unfortunate implications for ts-loader's test pack.

Updated 18/06/2017​

Whilst things did improve by fiddling with Windows Defender it wasn't a 100% fix which makes me wary. Interestingly, VS Code was always open when I did experience the issue and I haven't experienced it when it's been closed. So it may be the cause. I've opened an issue for this against the VS Code repo - it sounds like other people may be affected as I was. Perhaps this is VS Code and not Windows Defender. Watch that space...

Updated 12/07/2017​

The issue was VS Code. The bug has now been fixed and shipped last night with VS Code 1.14.0. Yay!

I'm a member of the Definitely Typed team - and hopefully I won't be kicked out for writing this. My point is this: .d.ts files should live with the package they provide typing information for, in npm / GitHub etc. Not separately.

I don't know about you but I personally feel that the following sentence may well be the saddest in the English language: