DEV Community: jcarloscandela

🚀 Speed Up Your CI/CD Pipelines in .NET with two tweaks

jcarloscandela — Fri, 01 Aug 2025 10:02:31 +0000

Hey devs! 👋

If your CI/CD pipelines sometimes feel a bit sluggish—especially in .NET projects—you're not alone. I recently noticed that some of our Azure DevOps pipelines were taking longer than they should, so I explored a few ways to optimize them.

It turns out, just two small tweaks in your YAML file can make a big difference. Here they are:

steps:
- checkout: self
  clean: true
  fetchDepth: 1
  fetchTags: false

- task: Cache@2
  displayName: 'Cache NuGet packages'
  inputs:
    key: 'nuget | "$(Agent.OS)" | **/packages.lock.json,**/*.csproj'
    restoreKeys: |
      nuget | "$(Agent.OS)"
    path: $(UserProfile)\.nuget\packages

✅ What these steps do

1. Optimized checkout

By default, Azure DevOps will retrieve all branches and tags from the repository during checkout—even ones you don't need for the current run. In large repositories with a long history, this can slow things down significantly.

By adding:

  fetchDepth: 1
  fetchTags: false

...you ensure that only the latest commit from the current branch is downloaded. Combined with:

  clean: true

...you also get a fresh workspace, which helps avoid conflicts or leftover files from previous runs.

🚀 Result: Faster checkouts, especially in repos with a lot of branches or tags.

2. NuGet Package Caching

This step sets up caching for your NuGet packages:

  path: $(UserProfile)\.nuget\packages

It prevents the pipeline from redownloading the same packages on every run. Instead, it restores from cache unless something has changed (like your packages.lock.json or .csproj files).

🚀 Result: Faster restores and less network overhead.

🔔 Note: This cache is specific to NuGet. If you're using other package managers like npm or yarn, you'll need different keys and paths.

🧹 Bonus Tip: Clean Up Old Branches & Tags

One overlooked cause of slow checkouts is the number of branches and tags in the repo. If your repository still contains feature branches or tags from a year (or more) ago, consider cleaning them up.

Removing old references helps Git operations run faster and keeps your repository healthier overall.

📈 Results

After applying these tweaks, our pipeline durations improved noticeably—especially during the checkout and restore phases.

If you're working with .NET projects and Azure DevOps pipelines, this is a low-effort, high-impact improvement you can make today.

💬 Have you optimized your pipelines in other ways? Share your tips in the comments—I'd love to hear what worked for you!

Detect and remove unused Angular code

jcarloscandela — Tue, 15 Jul 2025 07:21:05 +0000

Ever wonder if your Angular project is bloated with unused components, directives, pipes, or services? Say hello to ngx-unused — a powerful CLI tool that helps you find and eliminate unused Angular classes in your codebase.

If you're working on a large codebase or an Nx monorepo, ngx-unused can be a game-changer for code hygiene and performance.

🔍 What is `ngx-unused`?

ngx-unused is a utility that scans your Angular project and detects declared but unused classes that are decorated with:

@Component
@Directive
@Pipe
@Injectable

It analyzes the usage of these classes across your project and flags anything that isn't actually used — helping you identify dead code that can be removed safely.

🚀 Installation & Usage

You don’t even need to install it globally. Just run:

npx ngx-unused <directory> -p <tsconfig-path>

🔧 Options:

Option	Description
`<directory>`	Directory (or directories) to scan. You can pass multiple by separating with space.
`-p`, `--project`	Path to your main `tsconfig` file. For Nx projects, this is usually `tsconfig.base.json`.
`-h`, `--help`	Show help message.

📌 Note: The source root(s) and the tsconfig file must live under the same root directory.

🧪 Examples

Scan everything:

npx ngx-unused . -p tsconfig.base.json

Scan only specific libraries and apps:

npx ngx-unused libs apps/my-app -p tsconfig.base.json

🛠 How Does It Work?

It finds all classes decorated with Angular decorators (@Component, @Directive, @Pipe, @Injectable).
It checks if those classes are actually used in:
- TypeScript code
- Module metadata (declarations, providers, etc.)
It ignores:
- Test files (*.spec.ts)
- Simple imports/exports
- Usages in useClass or useExisting (these are considered used)

If a class isn't referenced in any meaningful way, it gets flagged.

📦 Output

Results are printed in the terminal, grouped by file. Here's an example:

✔ Scanning source files...
⚠ Unused Services:
  - src/app/shared/my-unused.service.ts → MyUnusedService
  - libs/util/logger.service.ts → LoggerService

✅ Exit Codes

Code	Meaning
0	No unused classes detected
1	Unused component/directive/pipe/service found
2	Invalid configuration

💡 Why You Should Use It

Keep your codebase lean and maintainable
Improve performance by eliminating dead code
Catch forgotten legacy files that are no longer needed
Great companion during refactors or audits
Simplify Angular version upgrades — removing unused code helps reduce complexity and potential migration issues when updating Angular versions (especially major ones)

🧼 Conclusion

ngx-unused is a minimalistic yet incredibly helpful tool for Angular developers looking to declutter their projects. Whether you’re working on a growing monorepo or tidying up a legacy app, it’s a must-have in your toolbox.

Give it a try:

npx ngx-unused . -p tsconfig.base.json

Let your Angular codebase breathe!

✍️ Have you used ngx-unused? Got tips or improvements to suggest? Drop a comment below!

How to Create a Library Package from an existing Angular App

jcarloscandela — Sat, 15 Jun 2024 21:02:20 +0000

Creating a library package from an existing Angular application can significantly streamline code reuse and modularity across different projects. In this guide, we'll walk through the process using the ng-packagr tool, with an example based on the Ionic Conference App.

Prerequisites

Before we begin, ensure you have an existing Angular project. For this example, we'll use the Ionic Conference App.

Clone the Ionic Conference App:

   git clone https://github.com/ionic-team/ionic-conference-app
   cd ionic-conference-app

Step 1: Install ng-packagr

First, install ng-packagr in your project:

npm install ng-packagr

Step 2: Create ng-package.json

Next, create a ng-package.json file in the root of your project with the following content:

{
    "$schema": "./node_modules/ng-packagr/ng-package.schema.json",
    "allowedNonPeerDependencies": [
        "@angular/common",
        "@angular/core",
        "@angular/forms",
        "@angular/platform-browser",
        "@angular/router",
        "@angular/service-worker",
        "@awesome-cordova-plugins/core",
        "@awesome-cordova-plugins/in-app-browser",
        "@capacitor/android",
        "@capacitor/app",
        "@capacitor/core",
        "@capacitor/device",
        "@capacitor/haptics",
        "@capacitor/ios",
        "@capacitor/keyboard",
        "@capacitor/splash-screen",
        "@capacitor/status-bar",
        "@ionic/angular",
        "@ionic/storage-angular",
        "cordova-plugin-inappbrowser",
        "core-js",
        "rxjs",
        "sw-toolbox",
        "wait-on",
        "webdriver-manager",
        "zone.js"
    ]
}

This configuration file specifies the dependencies that are allowed in the package. The app depends on those packages, so we need to add them inside allowedNonPeerDependencies.

Step 3: Create a Public API File

Create a public_api.ts file in the src folder to export the components and modules you want to make available for import in other projects. For example:

export * from './app/shared/shared.component';
export * from './app/shared/shared.module';

Step 4: Define Components and Modules

Define the components and modules you want to share. Here’s an example of a shared component and module:

`shared.component.ts`

import { Component } from '@angular/core';

@Component({
  selector: 'app-shared',
  template: `
    <div>
      <h2>Shared Component</h2>
      <p>This is a shared component created for reuse.</p>
    </div>
  `
})
export class SharedComponent { }

`shared.module.ts`

import { NgModule } from '@angular/core';
import { CommonModule } from '@angular/common';
import { SharedComponent } from './shared.component';

@NgModule({
  declarations: [
    SharedComponent
  ],
  imports: [
    CommonModule
  ],
  exports: [
    SharedComponent
  ]
})
export class SharedModule { }

Step 5: Update package.json Scripts

Add the following script to your package.json:

"scripts": {
  "package": "ng-packagr -p ng-package.json"
}

Run this script to generate the package in the dist folder:

npm run package

Step 6: Link the Package Locally

Once the package is generated, navigate to the dist folder and create a link to reuse the package locally:

cd dist
npm link

Step 7: Consume the Library in Another Project

In the project where you want to use the library, run the following command to link the library:

npm link ionic-conference-app

Import the necessary components and modules from the library and use them in your project. If you encounter build errors during execution, add the following to angular.json to resolve symlink issues:

"architect": {
  "build": {
    "options": {
      "preserveSymlinks": true
    }
  }
}

Step 8: Make Changes and Rebuild the Package

If you need to make changes to your library package, update the code as needed and then run the packaging script again to generate the updated package:

Make your changes to the components, modules, or any other part of the library.
Run the packaging script to rebuild the package:

   npm run package

Conclusion

By following these steps, you can efficiently create a library package from an existing Angular application and reuse components and modules across different projects. This approach not only promotes code reuse but also simplifies maintenance and updates. Happy coding!

Managing Public and Private Repositories in a Project

jcarloscandela — Fri, 26 Jan 2024 21:00:45 +0000

Projects often require a combination of public and private repositories to manage code effectively. This strategy is particularly useful for maintaining an open-source version while safeguarding proprietary or sensitive information. Below, we'll walk through the process using GitHub, but the principles apply to any Git hosting service like Bitbucket or GitLab.

Forking a Public Repository

To start, we'll fork a public repository into our account. Let's use GitHub for this example, but the process is similar elsewhere. Suppose we're forking a blog template built with Astro:

Step 1: Fork the public repository to your account. For instance:

Blog Template

Step 2: Clone the forked repository to your local machine. Adjust the URL with your username:

git clone https://github.com/yourusername/blog-template

Creating a Private Repository

Next, we need a private repository for internal development. Let's call it personal-blog-template. This repository will house content not intended for public viewing, such as personal blog posts.

Adding the Private Repository as a Remote

To interact with the private repository, we'll add it as a remote:

git remote add private https://github.com/yourusername/personal-blog-template

Verify the addition:

git remote -v

Making Changes and Pushing to the Private Repository

Now, let's upload changes to the private repository. Create a new branch to prevent conflicts:

git checkout -b release

Make desired changes and commit them:

git add .
git commit -m "Add some changes to the README.md file"

Push changes to the private repository:

git push private release

Integrating Changes into the Public Repository

Suppose we want to merge changes from the private repository into the public one.

Fetch changes from the private repository:

git fetch private

Merge the changes into the public repository:

git merge private/release

Conclusion

Managing both public and private repositories within a project is essential for maintaining transparency while protecting sensitive information. Whether for open-source projects or internal development, this approach ensures flexibility and security. By following these steps, you can effectively collaborate and manage your project across multiple repositories.

For enhanced control, tools like Husky can prevent accidental uploads of sensitive branches to public repositories. Experiment with these techniques to streamline your workflow and safeguard your project's integrity. Thank you for reading!

How to translate web page titles with Angular

jcarloscandela — Wed, 11 Jan 2023 21:53:39 +0000

Since Angular 15 we have the possibility to modify the title of the page from the routing. It is as simple as doing the following:

const routes: Routes = [
    {
        path: 'login',
        component: LoginComponent,
        title: 'Login'
    }
];

It is a very comfortable way of giving a title to any page of our project and being able to know where you were when we changed tabs in the browser. What if we want to translate the title?

The best way is to create a resolver. What is an Angular resolver?
A resolver allows us to get data before navigating to the new route.

To make a resolver we have to implement the Resolve interface. We also need a service to translate our translations keys, in this case I am using the package @ngx-translate/core

custom-title.resolver.ts

import { Injectable } from '@angular/core';
import { Resolve, ActivatedRouteSnapshot } from '@angular/router';
import { TranslateService } from '@ngx-translate/core';

@Injectable({ providedIn: 'root' })
export class CustomTitleResolver implements Resolve<string> {
    constructor(
        private _translateService: TranslateService,
    ) {}

    resolve(route: ActivatedRouteSnapshot): Promise<string> {
        if (!route.data.titleKey) {
            return Promise.resolve('Default title');
        }

        return Promise.resolve(
            this._translateService.instant(route.data.titleKey)
        );
    }
}

Now we go back to our routing file, we add the resolver and we have to pass the key of our translation. It will look like this:

const routes: Routes = [
    {
        path: 'login',
        component: LoginComponent,
        title: CustomTitleResolver,
        data: { titleKey: 'Login'}
    }
];

With all this, we now have a way to translate all the titles of our application, we just have to add the Resolver and the translation key to each of the routes. I hope it helps you, regards.

Safe reflection using TypeScript

jcarloscandela — Thu, 22 Dec 2022 19:44:31 +0000

Reflection

Reflection is a good way to avoid redundant code. I give you an example, imagine that we have the following code:

if(object.propertyA != null){
    console.log(object.propertyA);
}

if(object.propertyB != null){
    console.log(object.propertyB);
}

if(object.propertyC != null){
    console.log(object.propertyC);
}

A good way to improve it is avoiding the repeated code as follows. We create an array of strings with the properties on which we want to execute the action

const properties: string['propertyA', 'propertyB', 'propertyC'];

properties.forEach(property => {
    const value = Reflect.get(obj, property)
    if(value != null){
        console.log(value);
    }
});

So far so good, but what happens if we modify the name of the variables of the type of the object? Code we implemented in the past would fail and we wouldn't notice when we made the change.

How can we solve this? Creating a Proxy class

Proxy

What is a proxy? A proxy object enables you to create a proxy for another object, which can intercept and redefine fundamental operations for that object.

First of all we must retrieve the type we are using from the original object which is the following:

class ObjectType {
    propertyA: string;
    propertyB: number;
    propertyC: boolean;
}

How do we extract the properties of the object? Using the next function:

private proxiedPropertiesOf<TObj>() {
    return new Proxy({}, {
        get: (_, prop) => prop,
        set: () => {
        throw Error('Set not supported');
        },
    }) as {
        [P in keyof TObj]?: P;
    };
}

This allows us to extract the types safely and the code would look like this:

const typeProperties = this.proxiedPropertiesOf<ObjectType>();

const properties: string[] =
    [
        typeProperties.propertyA, 
        typeProperties.propertyB, 
        typeProperties.propertyC
    ];

From now on, if we make any changes to the ObjectType model, if we modify the name of any property or remove it, the TypeScript compiler itself will show us the error.

I hope it has been useful, thank you for your time :)

Much of the information comes from the following link

DEV Community: jcarloscandela

🚀 Speed Up Your CI/CD Pipelines in .NET with two tweaks

✅ What these steps do

1. Optimized checkout

2. NuGet Package Caching

🧹 Bonus Tip: Clean Up Old Branches & Tags

📈 Results

Detect and remove unused Angular code

🔍 What is ngx-unused?

🚀 Installation & Usage

🔧 Options:

🧪 Examples

🛠 How Does It Work?

📦 Output

✅ Exit Codes

💡 Why You Should Use It

🧼 Conclusion

How to Create a Library Package from an existing Angular App

Prerequisites

Step 1: Install ng-packagr

Step 2: Create ng-package.json

Step 3: Create a Public API File

Step 4: Define Components and Modules

shared.component.ts

shared.module.ts

Step 5: Update package.json Scripts

Step 6: Link the Package Locally

Step 7: Consume the Library in Another Project

Step 8: Make Changes and Rebuild the Package

Conclusion

Managing Public and Private Repositories in a Project

Forking a Public Repository

Creating a Private Repository

Adding the Private Repository as a Remote

Making Changes and Pushing to the Private Repository

Integrating Changes into the Public Repository

Conclusion

How to translate web page titles with Angular

Safe reflection using TypeScript

Reflection

Proxy

🔍 What is `ngx-unused`?

`shared.component.ts`

`shared.module.ts`