DEV Community: Paweł Fraś

How overwriting NODE_OPTIONS can ruin your debugger in Visual Studio Code 😬

Paweł Fraś — Mon, 18 Nov 2024 21:36:59 +0000

When using Visual Studio Code daily, you may use JavaScript Debug Terminal to debug your Node.js apps. If you do so, one day, you may struggle with the same issue I did some time ago.

Problem

When I tried to run a Node.js application in the Javascript Debug Terminal, I noticed the debugger was not attaching to the process as it used to, regardless of whether breakpoints were set.

The problem was related to the NODE_OPTIONS I set in my terminal config file—not the fact that I added it, but the way I did it. It turned out that the debugger in VSC uses the special NODE_OPTIONS environment variable, and overwriting it may lead to unexpected behaviors.

Solution

Instead of overwriting the variable, you should extend it with your options. For example, the config file (.zshrc in my case) might contain something like this:

- export NODE_OPTIONS="--some-other-option=here"
+ export NODE_OPTIONS="$NODE_OPTIONS --some-other-option=here"

sidenote: This also applies to Cursor!

source: https://code.visualstudio.com/docs/nodejs/nodejs-debugging#_how-can-i-set-nodeoptions

Angular 17: Overcoming SSR Challenges Of The New 'application' Builder 🔎

Paweł Fraś — Tue, 12 Dec 2023 15:18:47 +0000

The new Angular builder introduced in version 17, named application, consolidates separate builders for CRS, SSR, and SSG into a single entity. This becomes the default choice when creating a new application.

Unfortunately, for applications with SSR, changes to the server.ts file, which contains the server implementation, are not reflected when running ng serve. This is cumbersome if you have some custom providers for your application specific for the server side. The same when comes to custom logic that depends on the request/response. In developer mode, these changes simply won't work.

As a workaround, you can run watch script for re-building your app on changes made in code and in the separate terminal, serve server.mjs file with flag --watch to be eager to changes in dist folder. It can be achievable by small adjustment in package.json:

"watch": "ng build --watch --configuration=development",
- "serve:ssr:<your-app-name>": "node dist/<your-app-name>/server/server.mjs"
+ "serve:ssr:<your-app-name>": "node --watch dist/<your-app-name>/server/server.mjs"

You can try this suggestion or switch back to previous builders: browser, server and ssr-dev-server - they are still supported, but by choosing them you'll lost advantages of esbuild .

There is a GitHub issue in Angular-CLI repository describing mentioned issue. Don't hesitate to share your thoughts and leave there 👍 reaction - let Angular Core team know about our struggles :)

Angular 17 ✨mapToCanActivate✨: Your Class Guards' Best Friend

Paweł Fraś — Mon, 09 Oct 2023 15:58:06 +0000

When you're updating your Angular app to version 16, you might notice that the CanActivate interface is now deprecated. If you're thinking about changing your class guards to functional ones (or injecting the class in a wrapper function like this:

() => inject(MyGuard).canActivate()

here's the deal - Angular 17 will probably come with a handy function called mapToCanActivate that should let you stick with your class guards as they are. Let's check out this example:

@Injectable({providedIn: 'root'})
export class AdminGuard {
  canActivate() {
    return true;
  }
}

const route: Route = {
  path: 'admin',
  canActivate: mapToCanActivate([AdminGuard]),
};

The function accepts an array as an argument, allowing you to pass all your guards for a specific route without having to create a separate wrapper for each one.

It seems like you can delay the refactoring for a bit and concentrate on your business requirements! 🙂

source: https://next.angular.io/api/router/mapToCanActivate