Allow globs in allowedCommonJsDependencies
#18058
Assignees
Labels
area: @angular-devkit/build-angular
devkit/build-angular:browser
feature
Issue that requests a new feature
Milestone
Comments
alan-agius4
added
devkit/build-angular:browser
needs: discussion
|
Another option would be to allow the package instead of the entrypoint. |
|
From #18025 (comment)
|
alan-agius4
added
area: @angular-devkit/build-angular
and removed
needs: discussion
|
I have a big list of warnings with DevExtreme Library using the long imports path, please add a glob match pattern like |
filipesilva
pushed a commit
that referenced
this issue
Jul 1, 2020
…t the package name With this change we add the functionality to also match an allowed dependency against a package name. The package name is retrieved from the rawRequest. Previously, users needed to add the request path which in some case might be a deep import. Ex: `zone.js/dist/zone-error`. With this change adding the package name example `zone.js` will suffice. Closes: #18058
filipesilva
pushed a commit
that referenced
this issue
Jul 1, 2020
…t the package name With this change we add the functionality to also match an allowed dependency against a package name. The package name is retrieved from the rawRequest. Previously, users needed to add the request path which in some case might be a deep import. Ex: `zone.js/dist/zone-error`. With this change adding the package name example `zone.js` will suffice. Closes: #18058
villelahdenvuo
pushed a commit
to villelahdenvuo/angular-cli
that referenced
this issue
Jul 6, 2020
…t the package name With this change we add the functionality to also match an allowed dependency against a package name. The package name is retrieved from the rawRequest. Previously, users needed to add the request path which in some case might be a deep import. Ex: `zone.js/dist/zone-error`. With this change adding the package name example `zone.js` will suffice. Closes: angular#18058
|
Ok is there anywhere we can complain about this warnings ? This is completely rediculus. From one issue and to the other to figure out how even angularfire / material and many others offer this warming. Should we go more public about this with high social profiles ? What the hell angular team?? This was not even in the upgrade guide. It's the first time since angular 2 that actually updating broke things. Can someone guide me where to track these issues with warnings? ( |
Please note that these are warnings, not breakages. So this upgrade has not broken anything. Moreover in the case of firebase, it is actually helping you. Previously you have unwittingly been using libraries that are packaged in a way that potentially are making your production bundles larger than they need to be. |
|
How exactly is it helping me if it's not documented in the upgrade guide ? Post upgrade and start searching ? This is the definition of a bad upgrade procedure. |
I would say it more friendly that this feature is not designed for real world applications. |
|
@JohnnyDevNull ? What do you mean with not designed for real world applications ? Are you using some imaginary world applications at your company ? If so how ? Enlighten me. Perhaps I need to get back to the matrix our investors and our clients. |
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
🚀 Feature request
Command (mark with an
x)Description
With NG10 I have noticed some CommonJS imports and I am now trying to hide some warnings that are save to hide. When I started adding one module name I noticed that I need to be very strict with the path, so importing
dayjs/locale/deis not affected bydayjsinallowedCommonJsDependencies, so I needed to add every import twice.Describe the solution you'd like
Allow globs in
allowedCommonJsDependencies(e.g.dayjs/locale/*) or let it know when addingdayjstoallowedCommonJsDependenciesthatdayjs/locale/deis related to it.Describe alternatives you've considered
Another solution would be to allow ignoring through a comment like eslint rule disabling. I noticed that this would be useful in one case where I add
zone.js/dist/zone-errorin myenvironment.ts. With a comment (e.g.@ts-ignore-import) I could ignore the warning here but would still get warnings when someone adds this line accidentally inenvironment.prod.ts.The text was updated successfully, but these errors were encountered: