Dynamic require conflict with packagers

[PRR24]

Added
... require("tty").isatty(1) ...
in version 1.0.1 results Angular compiler warning
./node_modules/picocolors/picocolors.js:3:163-170 - Warning: Critical dependency: require function is used in a way in which dependencies cannot be statically extracted.

Would be great if it was solved differently.

[alexeyraspopov]

@PRR24 is it your Angular app code that imports picocolors? How did the compiler end up parsing code of the library?

[PRR24]

There are number of indirect dependencies to picocolor from @angular-devkit/build-angular
Not sure which one of those specificly causes the issue to appear.

[PRR24]

Forgot to specify that the my issue appears with Angular 16.latest SSR build.

[belgattitude]

Got it also with latest nextjs app router when using kysely. Couldn't reproduce easily on an opensource repo, but the issue seems to exist

[someshwar-terkar]

Hey, any update on this issue?

[alexeyraspopov]

It should be an easy fix, I can probably get to it this week. Though I would still appreciate some info about how dis you end up in situation where the angular compiler started analyzing this dependency

[PRR24]

I think Angular has had the dependency for a long time. There are no issues with picocolors@1.0.0, which I forced my project to at this point.

If I would make a bold guess, I think the issue is arised from
@angular-devkit/build-angular -> @babel/core -> @babel/code-frame -> picocolors dependency.
But again, this is just a guess, no facts.

[readikus]

It should be an easy fix, I can probably get to it this week. Though I would still appreciate some info about how dis you end up in situation where the angular compiler started analyzing this dependency

Unfortunately, I can't seem to recreate this issue in a separate repo, so it's a challenge to share it.

My current project is a nextjs project, and the issue I am seeing in the console is:

Critical dependency: require function is used in a way in which dependencies cannot be statically extracted

Import trace for requested module:
./node_modules/picocolors/picocolors.js
./node_modules/@babel/code-frame/lib/index.js
./node_modules/html-validate/dist/es/browser.js
./src/my-file.ts

The related part of my-file is this:

import { HtmlValidate, Result, StaticConfigLoader } from 'html-validate/browser';

const createHtmlValidator = () => {
  const loader = new StaticConfigLoader({
    extends: ['html-validate:standard'],
    elements: ['html5'],
  });
  return new HtmlValidate(loader);
};

const isValidHTML = async (html: string, validator: HtmlValidate): Promise<boolean> => {
  try {
    const report = await validator.validateString(html);
    return report.valid;
  } catch (error) {
    console.error('ERROR VALIDATING HTML:', error);
    return false;
  }
};

export const validateHTML = async (html: string): Promise<Result[]> => {
  try {
    const validator = createHtmlValidator();
    const report = await validator.validateString(html);
    return report.results;
  } catch (error) {
    console.error('ERROR VALIDATING HTML:', error);
    return [];
  }
};

This may be completely unhelpful, but I ended up on this page, and spent some time trying to build a clean nextjs project to recreate this issue, and sadly that didn't reproduce the error.

[carlonoelle]

Look at my PR #71 for a possible fix for this if you still face the issue

[alexeyten]

I'm wonder shouldn't Angular use picocolors.browser.js?

[PRR24]

I'm wonder shouldn't Angular use picocolors.browser.js?

Angular SSR runs on server.

[AshtarCodes]

I am also getting this error in Next.js 13 with App router. One of my dependencies uses picocolors

[alexeyten]

I'm wonder shouldn't Angular use picocolors.browser.js?

Angular SSR runs on server.

Still not convinced. It's SS Rendering, so it must produce the same output as in browser.

[amakhrov]

It's server-side code only, via critters (used for inlining critical CSS). This code never runs in the browser.

angular-devkit/build-angular -> critters -> postcss -> picocolors

[alexeyten]

@alexeyraspopov
May be just use process.stdout.isTTY?

# Using Node v10.24.1
$ node -p '[process.version, process.stdout.isTTY]' | cat
[ 'v10.24.1', undefined ]
$ node -p '[process.version, process.stdout.isTTY]' 
[ 'v10.24.1', true ]

# Using Node v20.10.0
$ node -p '[process.version, process.stdout.isTTY]' | cat
[ 'v20.10.0', undefined ]
$ node -p '[process.version, process.stdout.isTTY]' 
[ 'v20.10.0', true ]