Option to disable CommonJS/AMD warnings.

[fudom]

Which @angular/* package(s) are relevant/related to the feature request?

compiler

Description

In a real world applications it's impossible to 100% avoid CommonJS/AMD dependencies. Either because of need or indirect dependencies which cannot be changed.

Docs

Proposed solution

Instead of filling the allowedCommonJsDependencies array, add an option to disable all warnings.

Alternatives considered

Or allow wildcard * to allow all.

[alan-agius4]

In a real world applications it's impossible to 100% avoid CommonJS dependencies

I don't really agree with this statement. Can you provide some explains of which libraries you are having trouble with? In general CJS libraries are not meant to be used in the browser.

[fudom]

I mean packages that are either CJS/AMD themselves or indirectly use CJS/AMD dependencies.
Like @ionic/storage, @turf, keycloak-js, dayjs, semver, etc.

Warning: foo.ts depends on 'dayjs'. CommonJS or AMD dependencies can cause optimization bailouts.

Warning: foo.ts depends on 'dayjs/plugin/relativeTime'. CommonJS or AMD dependencies can cause optimization bailouts.

Warning: foo.ts depends on 'dayjs/locale/foo'. CommonJS or AMD dependencies can cause optimization bailouts.

Warning: foo.ts depends on 'fast-xml-parser'. CommonJS or AMD dependencies can cause optimization bailouts.

Warning: foo.ts depends on 'jszip'. CommonJS or AMD dependencies can cause optimization bailouts.

Warning: foo.ts depends on 'ajv'. CommonJS or AMD dependencies can cause optimization bailouts.

Warning: foo.ts depends on 'markdown-it-header-sections'. CommonJS or AMD dependencies can cause optimization bailouts.

Warning: node_modules\keycloak-js\dist\keycloak.mjs depends on 'js-sha256'. CommonJS or AMD dependencies can cause optimization bailouts.

Warning: node_modules\keycloak-js\dist\keycloak.mjs depends on 'base64-js'. CommonJS or AMD dependencies can cause optimization bailouts.

Warning: node_modules\@turf\line-overlap\dist\es\index.js depends on 'deep-equal'. CommonJS or AMD dependencies can cause optimization bailouts.

Warning: node_modules\@turf\boolean-overlap\dist\es\index.js depends on 'geojson-equality'. CommonJS or AMD dependencies can cause optimization bailouts.

Warning: node_modules\@turf\buffer\dist\es\index.js depends on 'turf-jsts'. CommonJS or AMD dependencies can cause optimization bailouts.

Warning: node_modules\@ionic\storage\__ivy_ngcc__\fesm2015\ionic-storage.js depends on 'localforage'. CommonJS or AMD dependencies can cause optimization bailouts.

...

Some deps could be replaced with alternatives, others not. Dependencies must be chosen carefully. CJS/AMD warnings are unavoidable when using required packages. Directly or indirectly. It's utopian and wishful thinking to have only clean ESM in a complex real real world application. Finally, the developers should decide to generally allow such packages without having to maintain the array list. For example by adding "*" or separate property to suppress the warnings.

[angular-robot]

This feature request is now candidate for our backlog! In the next phase, the community has 60 days to upvote. If the request receives more than 20 upvotes, we'll move it to our consideration list.

You can find more details about the feature request process in our documentation.

[twoco]

I have a similar issue with that. In a larger project (monorepo) you cannot avoid CJS/AMD dependencies. There is a PR (#25931) which cannot be merged because of Contributor License Agreement (CLA). I'm ok with the CLA. But I don't have and don't want a Google account. So you can just do it ... Here's is my proposal. It's really simple and does not have any critical breaking impact.

Just add allowedRequests.has('*') to

angular-cli/packages/angular_devkit/build_angular/src/tools/esbuild/commonjs-checker.ts

Lines 86 to 88 in 2d2e799

	if (allowedRequests.has(request)) {
	notAllowed = false;
	} else {

if (allowedRequests.has('*') || allowedRequests.has(request)) {
  notAllowed = false;
} // else ... 

[fudom]

Not sure if any issue can reach 20 upvotes in this project (cli). Maybe with bots. It's like an indirect close. I understand the idea behind. But in this case, why not just implement this simple change regardless of this? With minimal effort and a powerful option that allows the developer to decide what to allow and what not. The developer would add a long list of all the packages anyway. It's just more effort, uglier and repeating task. Using wildcard in such cases isn't unusual. Why blocking this? Any concerns? Ignoring is just disrespectful.

[alan-agius4]

PRs are welcome add wildcard support.

[angular-robot]

Just a heads up that we kicked off a community voting process for your feature request. There are 20 days until the voting process ends.

Find more details about Angular's feature request process in our documentation.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}