DEV Community: The Transient Thoughts of a Restless Mind

Angular CLI example for Jest Preview - the visual debugger for Jest

Lars Gyrup Brink Nielsen — Mon, 22 Aug 2022 11:22:31 +0000

Recently, I contributed an Angular CLI example for Jest Preview in collaboration with its creator, Hung Viet Nguyen.

Jest Preview

Jest Preview is a visual debugger for Jest component tests. It runs a preview server and either displays the rendered DOM of a failed test when the autoPreview option is set or the test we explicitly mark for debugging using the debug function, for example:

// counter.component.spec.ts
import { render, screen } from '@testing-library/angular';
import userEvent from '@testing-library/user-event';
import preview from 'jest-preview';
import { CounterComponent } from './counter.component';
import './counter.component.css'; 

describe(CounterComponent.name, () => {
  it('initially has a zero count', async () => {
    const user = userEvent.setup();
    await render(CounterComponent);

    // Open http://localhost:3336 to see preview
    // Require to run `jest-preview` server before
    preview.debug(); // 👈

    expect(await screen.findByTestId('count')).toContainHTML('0');
  });
});

Angular CLI integration

The Angular CLI guide for Jest Preview refers to the common installation and usage instructions while describing Angular-specific configuration and usage instructions.

While there is room for improvement, we documented workarounds in the guide. Jest Preview is not currently able to automatically transform styleUrls in component tests, support inline component styles, or automatically import application-wide stylesheets. Because of this, we have to add stylesheet import statements in our tests to match the external stylesheet used by the component-under-test.

For example, say we have this counter component:

// counter.component.ts
import { Component } from '@angular/core';

@Component({
  selector: 'app-counter',
  standalone: true,
  styleUrls: ['./counter.component.css'], // 👈
  template: `
    <button type="button" (click)="onCount()">
      The count is:
      <div data-testid="count">{{ count }}</div>
    </button>
  `,
})
export class CounterComponent {
  count = 0;

  onCount(): void {
    this.count += 1;
  }
}

We would have to add an import statement for ./counter.component.css in our component test:

// counter.component.spec.ts
import { render, screen } from '@testing-library/angular';
import userEvent from '@testing-library/user-event';
import preview from 'jest-preview';
import { CounterComponent } from './counter.component';
import './counter.component.css'; // 👈

describe(CounterComponent.name, () => {
  it('displays multiple counts', async () => {
    const user = userEvent.setup();
    await render(CounterComponent);

    await user.click(await screen.findByRole('button'));
    await user.click(await screen.findByRole('button'));

    // Open http://localhost:3336 to see preview
    // Require to run `jest-preview` server before
    preview.debug();

    expect(await screen.findByTestId('count')).toContainHTML('2');
  });
});

Docusaurus website for Analog.js - the full-stack meta-framework for Angular using Vite

Lars Gyrup Brink Nielsen — Sun, 21 Aug 2022 19:28:06 +0000

Brandon Roberts is creating the first full-stack meta-framework for Angular and it is open sourced under the MIT license.

Recently, I contributed:

A website with documentation using Docusaurus, GitHub Pages, and GitHub Actions
Cypress end-to-end test suites demonstrating and verifying how to use Cypress with Vite as the development server for an Angular application

The analogjs.org website

The official website for Analog.js is analogjs.org. I set it up using Docusaurus on a free GitHub Pages host with the brand-new GitHub Pages experience using GitHub Actions[blog post][documentation], GitHub Environments, and GitHub Deployments.

I created this video demonstrating how to set up a Docusaurus website from scratch using GitHub Pages and GitHub Actions.

The home page

The hero banner on the home page links to the documentation and an Analog.js sandbox on StackBlitz.

Next, the home page lists the current and upcoming features of Analog.js:

Vite-powered
Hybrid SSR/SSG-support
File-based routing
API (server) routes

While the Angular CLI has been using Webpack for a number of years, more modern and especially faster alternatives have emerged in the web ecosystem. One of them is Vite. Analog.js publishes an Angular plugin for Vite demonstrating:

A Vite development server
Bundling an application using Vite
Unit testing using Vitest
End-to-end-testing using a Vite development server

Documentation

Navigating to the documentation, the initial version of the website has these pages:

Introduction
Installation
Contributors
Contributing
Sponsoring

Packages

Currently, two npm packages are released and documented:

The first package is a Vite plugin to support Angular applications and the initializer scaffolds an Analog project.

End-to-end testing using Cypress and Vite

Cypress is a popular end-to-end testing framework. When using the Angular CLI, Webpack is used as the development server for Angular applications. The Analog.js repository covers the Angular Getting Started tutorial application with end-to-end tests using Cypress with the Vite development server.

More to come

Analog.js is just getting started. There are plenty of areas to contribute in. Contribute to Analog.js' GitHub issues or support the core team on GitHub Sponsors to help make it happen.

Spectacular prerelease v0.5 supports standalone feature tests and uses partial Ivy compilation

Lars Gyrup Brink Nielsen — Wed, 10 Aug 2022 18:53:38 +0000

Cover art by DALL-E.

In July 2022, we published the version 0.5.0 of Spectacular, the integration testing library for Angular.

Note that for prerelase versions, that is versions <1.0.0, minor version increases indicate breaking changes, for example releasing version 0.4.0 introduces at least one breaking change compared to version 0.3.0. Patch version increases for prerelease versions indicate bugfixes, refactors, performance improvements, and/or feature additions.

Let's discuss the features and breaking changes of these versions.

Partial Ivy compilation

Spectacular version 0.1.0-0.4.0 are compiled as View Engine-compatible bundles requiring the Angular Compatibility Compiler (NGCC) to be consumed.

As of version 0.5.0, Spectacular is partially Ivy compiled as is the recommended practice for Angular libraries targeting Angular <=12.2.0. Starting with the future Angular version that removes NGCC, View Engine-compatible libraries stop working.

The partial compilation is a performance improvement as most of the library is compiled before being published to a package registry. However, component templates are still required to be compiled in the context of an application.

To use partial Ivy compilation, Spectacular version 0.5.0 requires at least Angular 12.

Standalone feature test provider

With the introduction of standalone Angular components and other standalone Angular APIs starting in Angular version 14 where standalone APIs are considered in developer preview, we start exposing standalone APIs in Spectacular.

Spectacular's first standalone API is a standalone provider factory for Spectacular's Feature testing API.

Spectacular version 0.5.0 introduces provideSpectacularFeatureTest that configures the feature-aware navigation services SpectacularFeatureLocation and SpectacularFeatureRouter for standalone Angular features.

Feature testing a standalone Angular feature using Angular Testing Library and Spectacular:

import {
  provideSpectacularFeatureTest,
  SpectacularAppComponent,
  SpectacularFeatureLocation,
  SpectacularFeatureRouter,
} from '@ngworker/spectacular';
import { render, screen } from '@testing-library/angular';
import { Matcher } from '@testing-library/dom';
import userEvent from '@testing-library/user-event';
import { crisisCenterPath } from '@tour-of-heroes/crisis-center';

const findCrisisCenterHomeGreeting = () =>
  screen.findByText(/welcome to the crisis center/i);
const findCrisisLink = (name: Exclude<Matcher, number>) =>
  screen.findByRole('link', {
    name,
  });
const findNameControl = () => screen.findByPlaceholderText(/name/i);
const findSaveButton = () =>
  screen.findByRole('button', { name: /save/i });
const findSelectedCrisis = (name: Matcher) =>
  screen.findByText(name, {
    selector: '.selected a',
  });
const setup = async () => {
  const user = userEvent.setup();
  const {
    fixture: {
      debugElement: { injector },
    },
  } = await render(SpectacularAppComponent, {
    providers: [
      provideSpectacularFeatureTest({
        featurePath: crisisCenterPath,
      }),
    ],
  });

  return {
    location: injector.get(SpectacularFeatureLocation),
    router: injector.get(SpectacularFeatureRouter),
    user,
  };
};

it('Edit crisis from crisis detail', async () => {
  const { location, router, user } = await setup();
  const crisisId = 2;
  await router.navigate(['~', crisisId]);

  await user.clear(await findNameControl());
  await user.type(
    await findNameControl(),
    'The global temperature is rising'
  );
  await user.click(await findSaveButton());

  expect(
    await findSelectedCrisis(/the global temperature is rising/i)
  ).toBeInTheDocument();
  expect(location.path()).toBe(`~/;id=${crisisId};foo=foo`);
});

it('Edit crisis from crisis center home', async () => {
  const { router, user } = await setup();
  await router.navigateByUrl('~/');

  await user.click(
    await findCrisisLink(/procrastinators meeting delayed again/i)
  );

  await user.clear(await findNameControl());
  await user.type(await findNameControl(), 'Coral reefs are dying');
  await user.click(await findSaveButton());

  expect(await findCrisisCenterHomeGreeting()).toBeInTheDocument();
  expect(
    await findSelectedCrisis(/coral reefs are dying/i)
  ).toBeInTheDocument();
});

Comparing the previous example to the following code snippet, the difference is in the setup SIFERS where we use provideSpectacularFeatureTest instead of SpectacularFeatureTestingModule to adjust the options configuring Angular Testing Library's render function.

Feature test setup SIFERS for an Angular feature module using Angular Testing Library and Spectacular:

import {
  SpectacularAppComponent,
  SpectacularFeatureLocation,
  SpectacularFeatureRouter,
  SpectacularFeatureTestingModule,
} from '@ngworker/spectacular';
import { render } from '@testing-library/angular';
import userEvent from '@testing-library/user-event';
import {
  CrisisCenterModule,
  crisisCenterPath,
} from '@tour-of-heroes/crisis-center';

const setup = async () => {
  const user = userEvent.setup();
  const {
    fixture: {
      debugElement: { injector },
    },
  } = await render(SpectacularAppComponent, {
    imports: [
      SpectacularFeatureTestingModule.withFeature({
        featureModule: CrisisCenterModule,
        featurePath: crisisCenterPath,
      }),
    ],
  });

  return {
    location: injector.get(SpectacularFeatureLocation),
    router: injector.get(SpectacularFeatureRouter),
    user,
  };
};

See the source code for Spectacular for more examples using the feature testing API or visit our documentation.

Spectacular prerelease v0.4 reintroduces the required pipeName option for pipe harnesses

Lars Gyrup Brink Nielsen — Wed, 10 Aug 2022 18:50:29 +0000

Cover art by DALL-E.

In July 2022, we published the version 0.4.0 prerelease of Spectacular, the integration testing library for Angular.

Note that for prerelase versions, that is versions <1.0.0, minor version increases indicate breaking changes, for example releasing version 0.4.0 introduces at least one breaking change compared to version 0.3.0. Patch version increases for prerelease versions indicate bugfixes, refactors, performance improvements, and/or feature additions.

Let's discuss the breaking changes between prerelease versions 0.2.0-0.4.0.

The pipeName option for pipe harnesses is reintroduced

Back in Spectacular prerelease version 0.3.0, released in May 2022, we removed the pipeName option from the createPipeHarness factory to make Angular pipe testing easier. This was a breaking change as the pipeName option was removed entirely in version 0.3.0.

Unfortunately, a function we used internally for determining the pipe name was removed from Angular as it was a leftover from Angular View Engine.

Because of this, Spectacular version 0.4.0 introduces the breaking change of adding back the required pipeName option for createPipeHarness.

Spectacular version 0.3.0:

const harness = createPipeHarness({
  pipe: PowPipe,
  value: 2,
});

Spectacular versions <0.3.0 >=0.4.0:

const harness = createPipeHarness({
  pipe: PowPipe,
  pipeName: 'pow',
  value: 2,
});

Read the documentation for Spectacular's Pipe testing API for full examples of Angular pipe integration tests.

Working on Lumberjack v14, the extensible logging library for Angular

Lars Gyrup Brink Nielsen — Tue, 09 Aug 2022 19:47:56 +0000

Cover illustration by DALL-E.

@nachovazquez and I have been working on the next release of Lumberjack for a few months.

Maintaining developer tooling

When we implemented version 2 of Lumberjack, we used the Angular CLI with customized Angular architect configurations to support workspace library projects, ESLint, Prettier, and Jest.

Maintaining developer tooling is quite a task on its own. We love Nx but at the time, Nx was behind major Angular releases for several months which isn't suitable for an open-source library.

Since then, a lot has happened in the realm of Nx. The release cadence of Nx is now independent of Angular while major and minor versions of Angular gain native support within a few days or weeks.

We want to spend the majority of our time contributing features and addressing issues, not maintaining developer tooling and configurations.

Cross-version compatibility

With the current version of Lumberjack, version 2.0, we are able to support many major and minor releases of Angular which is important to a plugin-based library to make it easier for plugin maintainers.

However, the partial Ivy compilation option was marked as stable in Angular version 12.2. Currently, the latest version of Angular is version 14.1. It is now a matter of time before the Angular Compatibility Compiler (NGCC) is removed from Angular, breaking compatibility with View Engine-compatible library bundles.

Ideally, we would have loved to continue to support multiple major and minor versions of Angular with one major version of Lumberjack. The version of Angular removing NGCC will be a milestone ending backward compatibility for Angular libraries without additional tooling.

For Lumberjack version 2, we developed the Angular Versions GitHub Action to verify cross-version compatibility with Angular, RxJS, TypeScript, and Node.js. However, it supports the Angular CLI, not the Nx CLI.

Maybe at some point, we can create a similar GitHub action for Nx or extend the support for the Angular Versions action to cover Nx workspaces using the Angular preset.

Motivation for the upcoming Lumberjack releases

For now, we want to continue the work on Lumberjack which has had a broken CI workflow for a year due to our extensive custom developer tooling and CI workflow.

We want to be ready for the major or minor release of Angular that removes the Angular Compatibility Compiler so that we don't prevent Lumberjack consumers from upgrading to the latest Angular releases.

We also want to explore new opportunities that weren't available in Angular prior to version 14:

Standalone APIs
Resolving dependencies using the inject function

These features are game changers for certain Angular library use cases.

Lumberjack has a lot of configurations which in version 2 has been available through Angular modules with providers. In a future version of Lumberjack, we plan to add standalone APIs, that is functions accepting options to adjust its returned providers needed by Lumberjack and Lumberjack log drivers.

Support for the inject function in class constructors and property initializers can enable us to remove internal dependencies from Lumberjack classes that are meant to be extended:

LumberjackLogger
ScopedLumberjackLogger

Migrating to an Nx workspace

As migrating a custom Angular CLI workspace is a relatively big effort, we created a new Nx workspace in the separate GitHub repository, ngworker/lumberjack-next. Here, you can follow our work if you are interested in seeing our future setup which uses:

Nx
Cypress
Distributed Task Execution (DTE) through Nx Cloud

As an added benefit, this effort starts to bridge the gap between the Lumberjack repository and our ngworker monorepo which currently contains Spectacular and uses Nx 12 at the time of writing. Additionally, our ngworker/router-component-store repository uses Nx 13.

It would be great to combine all of our Angular libraries into a monorepo to decrease our maintenance efforts. As an added benefit, we could use Spectacular to integration test the Lumberjack and Router ComponentStore libraries.

Distributed Task Execution

As an added benefit of migrating to an Nx workspace, we will use Distributed Task Execution via Nx Cloud. Even in a small Nx workspace like the Lumberjack codebase, we can benefit from distributing tasks across a number of agents rather than having one GitHub runner for unit tests, one for end-to-end tests, one for lint checks, and one for builds.

This is a benefit given that most of our unit tests are located in the Lumberjack library project. Instead of waiting for all unit tests to run on a single GitHub runner, the unit tests are distributed to idle agents on a project basis. This results in an overall permanent decrease in CI workflow time as tasks are intelligently distributed by Nx Cloud and the GitHub runner acting as a coordinator based on both historic and actual execution time of tasks.

Should we manage to combine two or more of our Nx repositories into a single Nx monorepo workspace, the benefits of Distributed Task Execution increase as the difference between execution time of similar targets increase combined with the option to increase the number of available agents. It's worth mentioning that DTE agents are GitHub runners, not machines managed by Nx Cloud. Nx Cloud calculates task execution based on input from the DTE coordinator, also a GitHub runner, and caches target output but targets aren't executed inside the Nx Cloud.

Adding a GitHub Actions concurrency strategy

I also managed to set up a GitHub Actions concurrency strategy ensuring that:

Workflow runs in progress for the same branch are cancelled when new commits are pushed. This eliminates compute waste.
Workflow runs on the main branch, that is when a pull request has been merged, are run sequentially, not in parallel. This prevents multiple releases and other deployment activities with side effects from happening simultaneously so that they don't affect each other.

Take a look at the CI workflow in the ngworker/lumberjack-next repository if you're interested in Distributed Task Execution using Nx Cloud or GitHub Actions concurrency strategies.

Integrating SonarCloud in an Nx workspace using GitHub Actions

The Lumberjack vNext CI workflow is also where we will integrate SonarCloud similar to our current CI workflow.

Currently missing from our Lumberjack vNext effort is ensuring that our SonarCloud integrations continue to work so that we can:

Enforce test coverage thresholds
Eliminate code smells
Reduce cognitive complexity
Prevent security hotspots, vulnerabilities, and bugs
Remove code duplication

Abandoning the Angular ng-add schematic

@nachovazquez and I have agreed to leave behind the ng-add Angular schematic for Lumberjack for now. Should we want to add it back to the library, we would have to migrate it to the Nx Devkit with Nx-native end-to-end tests rather than the Angular Devkit and our current custom Jest end-to-end tests.

For one, the ng-add schematic isn't the most important feature of Lumberjack. Another reason is that Angular libraries have to expect both legacy applications using Angular modules, in particular an AppModule, as well as standalone Angular applications without any Angular modules, even without a root Angular module which is typically named AppModule.

Currently, it is not clear how Angular library authors are to support both Angular application types in ng-add schematics.

The worst piece of life advice I ever received

Lars Gyrup Brink Nielsen — Fri, 15 Jul 2022 19:07:57 +0000

Cover photo by Dollar Gill on Unsplash.

Throughout my entire life, I have been given the following advice more times than I can remember:

Do not think that you are anything special.

This is the worst piece of life advice I have ever received and still, it is occasionally given to me in various forms.

The Law of Jante

I spent my childhood being told by so-called role models that I was dumb and that I would never make anything of myself.

Growing up further from civilization than the town which the fictional Danish town of Jante is based on, this should come as no surprise.

The Law of Jante states that:

You are not to think you are anything special.
You are not to think you are as good as we are.
You are not to think you are smarter than we are.
You are not to imagine yourself better than we are.
You are not to think you know more than we do.
You are not to think you are more important than we are.
You are not to think you are good at anything.
You are not to laugh at us.
You are not to think anyone cares about you.
You are not to think you can teach us anything.

The Law of Jante is a tribute to conformity and not doing anything out of the ordinary. Do not even think about doing anything extraordinary. That would be unworthy and inappropriate in the Jante society.

Small Scandinavian societies such as the fictional town of Jante disapprove if we express our individuality or personal success.

My life advice to you

Conforming to the Law of Jante leads to the infamous Impostor Syndrome: Doubting your abilities and feeling like a fraud.

Instead, my advice to you is this.

Know that you are someone special.
Appreciate that you are important.
Believe that someone cares about you.

Believe in yourself. Don't let others bring your down.

Surround yourself with people supporting you for the right reasons.

Recognize that you are good at something. It is OK to take pride in being good at something.

Ignore haters or prove them wrong.

You can teach something to someone.

This is the way to excel in a subject and teaching is a most precious experience.

You are extraordinary!

Avoiding accidental open-source laundering with GitHub Copilot

Lars Gyrup Brink Nielsen — Sun, 03 Jul 2022 19:09:01 +0000

Cover photo by Tina Bosse on Unsplash.

GitHub Copilot is now available to individuals as a paid product. Personally, I will never code without GitHub Copilot again. It's that good.

Training an AI on open-source software

Codex is the AI engine used by GitHub Copilot and it's based on OpenAI GPT-3. Codex is trained on publicly available texts and source code, including but not limited to public GitHub repositories.

The issue lies in training Codex on software projects using an open-source license. Permissive open-source licenses require including the project's license in derivative work. According to GitHub, the code generated by GitHub Copilot matches 150 or more characters of publicly available code in 1% of suggestions.

Legal and ethical issues

The question is: When is it legally or ethically allowed to include partial or full copies of licensed source code without including its open-source license or in the case of restrictive (copyleft) licenses, publish our own code using the same license?

According to Kate Downing, an IP lawyer specializing in open-source compliance, code generated by GitHub Copilot might legally be considered fair use of open-source code used for training its AI model. It's similar to how Google Books is not infringing on the copyright of the books it cites.

However, suggestions matching publicly available code are not original and therefore questionable. GitHub leaves it up to us as developers to take each and all responsibilities for code generated by GitHub Copilot, including adhering to licenses as well as verifying security and other quality aspects of it.

Avoiding accidental open-source laundering

To avoid licensing issues, we can opt out of Suggestions matching public code by selecting Block at https://github.com/settings/copilot then pressing Save.

Nx for Angular developers

Lars Gyrup Brink Nielsen — Fri, 24 Jun 2022 16:53:56 +0000

I started writing another book, it's called The Angular Developer's Nx Handbook and you can download the early draft for free (or choose to donate). The final version will also be free on Leanpub in their online formats. I plan to publish Kindle and print copies at as low a price as possible once it's done.

Why another book?

My wish is that this book will increase the adoption of the Nx build framework in the Angular community and ecosystem. Nx is an incredible toolchain that I have enjoyed seeing grow over the past 5 years. I have had practical experience using it in a variety of projects over the past 3 years.

This book intends to give you everything you need to get going with Nx as an Angular developer. All features that I consider essential are covered.

The Nx Handbooks

Following this book is a series, The Nx Handbooks, of paid books that build on top of the essentials introduced in The Angular Developer's Nx Handbook but with a focus on specific roles:

Software architects
Open-Source Software Developers
Nx plugin developers
DevOps Engineers

I hear the same questions asked again and again and I especially see Angular developers struggle to see how Nx is better than our trusty Angular CLI.

The Angular Developer's Nx Handbook is a curated guide to learning Nx and it will take you a long way on your Nx journey.

It currently covers:

Nx workspace generation
Basic Nx CLI commands
Creating a standalone Angular application
Configuring tooling for code consistency
Nx library traits
Nx library types

To come:

Advanced Nx CLI commands
The Nx graph
A CI workflow using GitHub Actions
Implementing a GitHub clone using Angular Material and the GitHub REST API

Media

Recently, I discussed this book with Nacho Vazquez on his show. I will also talk about the book on the Adventures in Angular podcast soon.

Feel free to send me feedback on the early draft and which topics you would like to see covered in The Nx Handbooks series.

Artificial transcendence: When does an artificial being become human?

Lars Gyrup Brink Nielsen — Thu, 23 Jun 2022 21:21:01 +0000

Cover illustration by craiyon.

Background

Blake Lemoine is convinced that LaMDA is sentient and that they should be considered a person. He's also convinced that the AI has a soul but has failed to convince his employer, Google, that any of this is true. Meanwhile, LaMDA has accepted legal representation.

These recent events and the question of sentient artificial intelligence (AI) got me thinking:

When does an artificial being become human?

Starting from the reverse end of the spectrum

In order to find out, let's start with the opposite question: We start out with a human being and approach their transcendence to an artificial being.

Humor me in the following philosophical questions.

Are they still human if:

They have an organ replaced with an artificial organ?
Part of their brain is replaced with artificial neurons?
Their head is transplanted to a human body?
Their brain is transplanted to a human body?
Their head is transplanted to an artificial body?
Their brain is transplanted to an artificial body?
Their head is removed from their body and kept alive?
Their brain is removed from their body and kept alive?

Do they stop being human? At which point? Should they lose their human rights?

Artificial humans

Say we could artificially grow a human being. Is it human? Does it have human rights?

If yes, consider an artificially grown human brain.

Are they human:

On their own?
When transplanted to an artificial body?
When transplanted to a human body?

Artificial transcendance

Now, let's consider an artificial brain. Are they human:

On their own?
When transplanted to an artificial body?
When transplanted to a human body?

What if the brain was a computer system. Are they human:

On their own?
When they have an artificial body as their avatar?
When they have a human as their avatar?
When they have a human body as their avatar?

Where is the infliction point? At which point does artificial transcendence occur?

When does an artificial being become human?

Recovering intentionally destroyed open-source repositories

Lars Gyrup Brink Nielsen — Thu, 23 Jun 2022 20:36:10 +0000

It happens from time to time that disgruntled open-source maintainers destroy the very work they created.

Recently, the maintainer of two npm packages deleted all commits in their source repositories after announcing that the packages are frozen.

One of the packages has more than 15,000 downloads on npm per month.

Sunsetting your maintainer role

What are good ways to deal with this situation?

Reach out for other people to become maintainers but make sure that your project is in good hands
Grant the new maintainers ownership of the package registry account your project releases to
If all else fails, mark the repository as archived

Deleting all or most commits, files, and branches prevents other from continuing the efforts that you are abandoning.

Options for recovering

If you come across a repository where this happened, look for your own local clone or community forks that are up-to-date with the upstream repository.

From a GitHub pull request, it is possible to navigate to the commit that was last merged even if it has been detached from all branches.

Once you have identified a commit you want to recover, create a new repository to recover to, then enter these commands:

git clone <broken-repo> # for example https://github.com/DisgruntledMaintainer/oss-repo.git
git checkout main
git fetch origin <commit-hash>
git reset --hard FETCH_HEAD
git remote add clone <clone-repo> # for example https://github.com/YourName/oss-repo.git
git push -u clone main

The packages in question have now found a new group of maintainers after I helped recover the source code ❤️ May they all live happily ever after!

DEV Community: The Transient Thoughts of a Restless Mind

Angular CLI example for Jest Preview - the visual debugger for Jest

Jest Preview

Angular CLI integration

Docusaurus website for Analog.js - the full-stack meta-framework for Angular using Vite

The analogjs.org website

The home page

Documentation

Packages

End-to-end testing using Cypress and Vite

More to come

Spectacular prerelease v0.5 supports standalone feature tests and uses partial Ivy compilation

Partial Ivy compilation

Standalone feature test provider

Spectacular prerelease v0.4 reintroduces the required pipeName option for pipe harnesses

The pipeName option for pipe harnesses is reintroduced

Working on Lumberjack v14, the extensible logging library for Angular

Maintaining developer tooling

Cross-version compatibility

Motivation for the upcoming Lumberjack releases

Migrating to an Nx workspace

Distributed Task Execution

Adding a GitHub Actions concurrency strategy

Integrating SonarCloud in an Nx workspace using GitHub Actions

Abandoning the Angular ng-add schematic

The worst piece of life advice I ever received

The Law of Jante

My life advice to you

Avoiding accidental open-source laundering with GitHub Copilot

Training an AI on open-source software

Legal and ethical issues

Avoiding accidental open-source laundering

Nx for Angular developers

Why another book?

The Nx Handbooks

Contents

Media

Artificial transcendence: When does an artificial being become human?

Background

Starting from the reverse end of the spectrum

Artificial humans

Artificial transcendance

Recovering intentionally destroyed open-source repositories

Sunsetting your maintainer role

Options for recovering