angular/goldens/public-api/compiler-cli/error_code.md

93 lines
3.1 KiB
Markdown
Raw Normal View History

## API Report File for "angular-srcs"
> Do not edit this file. It is a report generated by [API Extractor](https://api-extractor.com/).
```ts
// @public (undocumented)
export enum ErrorCode {
COMPONENT_IMPORT_NOT_STANDALONE = 2011,
COMPONENT_INVALID_SHADOW_DOM_SELECTOR = 2009,
// (undocumented)
COMPONENT_MISSING_TEMPLATE = 2001,
COMPONENT_NOT_STANDALONE = 2010,
COMPONENT_RESOURCE_NOT_FOUND = 2008,
COMPONENT_UNKNOWN_IMPORT = 2012,
// (undocumented)
CONFIG_EXTENDED_DIAGNOSTICS_IMPLIES_STRICT_TEMPLATES = 4003,
// (undocumented)
CONFIG_EXTENDED_DIAGNOSTICS_UNKNOWN_CATEGORY_LABEL = 4004,
// (undocumented)
CONFIG_EXTENDED_DIAGNOSTICS_UNKNOWN_CHECK = 4005,
// (undocumented)
CONFIG_FLAT_MODULE_NO_INDEX = 4001,
// (undocumented)
CONFIG_STRICT_TEMPLATES_IMPLIES_FULL_TEMPLATE_TYPECHECK = 4002,
// (undocumented)
DECORATOR_ARG_NOT_LITERAL = 1001,
// (undocumented)
DECORATOR_ARITY_WRONG = 1002,
DECORATOR_COLLISION = 1006,
// (undocumented)
DECORATOR_NOT_CALLED = 1003,
// (undocumented)
DECORATOR_UNEXPECTED = 1005,
DIRECTIVE_INHERITS_UNDECORATED_CTOR = 2006,
// (undocumented)
DIRECTIVE_MISSING_SELECTOR = 2004,
DUPLICATE_VARIABLE_DECLARATION = 8006,
HOST_BINDING_PARSE_ERROR = 5001,
HOST_DIRECTIVE_COMPONENT = 2015,
HOST_DIRECTIVE_INVALID = 2013,
HOST_DIRECTIVE_NOT_STANDALONE = 2014,
IMPORT_CYCLE_DETECTED = 3003,
IMPORT_GENERATION_FAILURE = 3004,
INJECTABLE_DUPLICATE_PROV = 9001,
fix(compiler-cli): exclude abstract classes from `strictInjectionParameters` requirement (#44615) In AOT compilations, the `strictInjectionParameters` compiler option can be enabled to report errors when an `@Injectable` annotated class has a constructor with parameters that do not provide an injection token, e.g. only a primitive type or interface. Since Ivy it's become required that any class with Angular behavior (e.g. the `ngOnDestroy` lifecycle hook) is decorated using an Angular decorator, which meant that `@Injectable()` may need to have been added to abstract base classes. Doing so would then report an error if `strictInjectionParameters` is enabled, if the abstract class has an incompatible constructor for DI purposes. This may be fine though, as a subclass may call the constructor explicitly without relying on Angular's DI mechanism. Therefore, this commit excludes abstract classes from the `strictInjectionParameters` check. This avoids an error from being reported at compile time. If the constructor ends up being used by Angular's DI system at runtime, then the factory function of the abstract class will throw an error by means of the `ɵɵinvalidFactory` instruction. In addition to the runtime error, this commit also analyzes the inheritance chain of an injectable without a constructor to verify that their inherited constructor is valid. BREAKING CHANGE: Invalid constructors for DI may now report compilation errors When a class inherits its constructor from a base class, the compiler may now report an error when that constructor cannot be used for DI purposes. This may either be because the base class is missing an Angular decorator such as `@Injectable()` or `@Directive()`, or because the constructor contains parameters which do not have an associated token (such as primitive types like `string`). These situations used to behave unexpectedly at runtime, where the class may be constructed without any of its constructor parameters, so this is now reported as an error during compilation. Any new errors that may be reported because of this change can be resolved either by decorating the base class from which the constructor is inherited, or by adding an explicit constructor to the class for which the error is reported. Closes #37914 PR Close #44615
2022-01-04 18:03:30 +00:00
INJECTABLE_INHERITS_INVALID_CONSTRUCTOR = 2016,
INLINE_TCB_REQUIRED = 8900,
INLINE_TYPE_CTOR_REQUIRED = 8901,
INVALID_BANANA_IN_BOX = 8101,
MISSING_CONTROL_FLOW_DIRECTIVE = 8103,
MISSING_NGFOROF_LET = 8105,
MISSING_PIPE = 8004,
MISSING_REFERENCE_TARGET = 8003,
NGMODULE_BOOTSTRAP_IS_STANDALONE = 6009,
NGMODULE_DECLARATION_IS_STANDALONE = 6008,
NGMODULE_DECLARATION_NOT_UNIQUE = 6007,
NGMODULE_INVALID_DECLARATION = 6001,
NGMODULE_INVALID_EXPORT = 6003,
NGMODULE_INVALID_IMPORT = 6002,
NGMODULE_INVALID_REEXPORT = 6004,
NGMODULE_MODULE_WITH_PROVIDERS_MISSING_GENERIC = 6005,
NGMODULE_REEXPORT_NAME_COLLISION = 6006,
NGMODULE_VE_DEPENDENCY_ON_IVY_LIB = 6999,
NULLISH_COALESCING_NOT_NULLABLE = 8102,
OPTIONAL_CHAIN_NOT_NULLABLE = 8107,
// (undocumented)
PARAM_MISSING_TOKEN = 2003,
// (undocumented)
PIPE_MISSING_NAME = 2002,
SCHEMA_INVALID_ATTRIBUTE = 8002,
SCHEMA_INVALID_ELEMENT = 8001,
SPLIT_TWO_WAY_BINDING = 8007,
SUFFIX_NOT_SUPPORTED = 8106,
fix(language-service): show suggestion when type inference is suboptimal (#41072) The Ivy Language Service uses the compiler's template type-checking engine, which honors the configuration in the user's tsconfig.json. We recommend that users upgrade to `strictTemplates` mode in their projects to take advantage of the best possible type inference, and thus to have the best experience in Language Service. If a project is not using `strictTemplates`, then the compiler will not leverage certain type inference options it has. One case where this is very noticeable is the inference of let- variables for structural directives that provide a template context guard (such as NgFor). Without `strictTemplates`, these guards will not be applied and such variables will be inferred as 'any', degrading the user experience within Language Service. This is working as designed, since the Language Service _should_ reflect types exactly as the compiler sees them. However, the View Engine Language Service used its own type system that _would_ infer these types even when the compiler did not. As a result, it's confusing to some users why the Ivy Language Service has "worse" type inference. To address this confusion, this commit implements a suggestion diagnostic which is shown in the Language Service for variables which could have been narrowed via a context guard, but the type checking configuration didn't allow it. This should make the reason why variables receive the 'any' type as well as the action needed to improve the typings much more obvious, improving the Language Service experience. Fixes angular/vscode-ng-language-service#1155 Closes #41042 PR Close #41072
2021-03-03 23:06:21 +00:00
SUGGEST_STRICT_TEMPLATES = 10001,
SUGGEST_SUBOPTIMAL_TYPE_INFERENCE = 10002,
// (undocumented)
SYMBOL_NOT_EXPORTED = 3001,
TEMPLATE_PARSE_ERROR = 5002,
TEXT_ATTRIBUTE_NOT_BINDING = 8104,
UNDECORATED_CLASS_USING_ANGULAR_FEATURES = 2007,
UNDECORATED_PROVIDER = 2005,
// (undocumented)
VALUE_HAS_WRONG_TYPE = 1010,
// (undocumented)
VALUE_NOT_LITERAL = 1011,
WARN_NGMODULE_ID_UNNECESSARY = 6100,
WRITE_TO_READ_ONLY_VARIABLE = 8005
}
// (No @packageDocumentation comment for this package)
```