iSharkFly-Docs
/
angular-docs-cn
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
angular-docs-cn/third_party
History
George Kalpakas ab47f417d6 test(core): fix `Function#name` shim used in IE11 (#41439) 
Since IE11 does not support `Function#name`, we use a shim in tests that
parses the stringified function to extract the name. Previously, that
shim would cache the computed name on the function to speed up future
invocations. However, this resulted in incorrect values for functions
that "extended" other functions (such as the code generated by
TypeScript when downleveling ES2015 classes that extended other
classes).

To avoid issues such as #41416 (see also [internal discussion][1]), this
commit removes the caching of names. This is not expected to noticeably
affect performance, since (a) it is only used in tests, (b) it is only
used on browsers that do not natively support `Function#name` (i.e.
IE11) and (c) accessing function names is rare and inexpensive compared
to other operations that happen during testing.

[1]: https://angular-team.slack.com/archives/CB4UC1932/p1617285258058000

PR Close #41439
 		2021-04-05 08:56:17 -07:00
..
fonts.google.com/open-sans build: fix routing playground example using external resource (#28490) 2019-02-04 16:51:11 -05:00
github.com/google/material-design-icons ci: Remove old vendoring solution in favor of relying on yarn-path (#35083) 2020-02-06 15:30:51 -08:00
README.md docs: add a README for third_party usage (#28651) 2019-02-12 09:54:43 -08:00
shims_for_IE.js test(core): fix `Function#name` shim used in IE11 (#41439) 2021-04-05 08:56:17 -07:00

README.md

third_party vendored sources in Angular

TL;DR: don't copy sources into this repo

All sources in this repo should be authored from scratch by the committer. Don't copy sources you've found in any other location.

What if I have a good reason?

We do "vendor in" some sources, in cases where we do not want our users to have a transitive dependency. For example, to make testing more reliable, we copy a font into our repo. That allows our integration tests to run without dynamically requesting that font.

Follow these guidelines for adding sources under third_party:

  1. Only vendor sources with compatible licenses. Apache 2.0 and MIT are good. Any other licenses, check with your team lead so we can verify our ability to comply with the license.
  2. Preserve the license for code. The best thing to do is copy the entire LICENSE file along with the sources.
  3. Indicate where the sources came from. Our convention is to create a directory based on the URL where the sources were fetched. Add version number or if missing, the retrieval date, as a comment in the build file just above the license() call. Example: https://github.com/angular/angular/blob/master/third_party/fonts.google.com/open-sans/BUILD.bazel
  4. Avoid changing the files you fetched. If you make any changes to the sources, first commit the original, then in a separate commit, make your edits. include another metadata file listing your changes, like https://github.com/bazelbuild/rules_nodejs/blob/master/third_party/github.com/source-map-support/LOCAL_MODS.md
  5. Any bundle or distribution which includes this code needs to propagate the LICENSE file or content. Talk to your TL to make sure this is done correctly.

Under Bazel

This directory is treated specially by Bazel.

All BUILD.bazel files under third_party are required to have a licenses statement. See https://docs.bazel.build/versions/master/be/functions.html#licenses

Note that we don't yet have a way to enumerate the licenses and include them in our distribution. Follow https://github.com/bazelbuild/bazel/issues/188