Error: node_modules/primeng/api/messageservice.d.ts:3:22 - error NG6002: Appears in the NgModule.imports of AppModule, but could not be resolved
to an NgModule class.
This likely means that the library (primeng/api) which declares MessageService has not been processed correctly by ngcc, or is not compatible with Angular Ivy. Check if a newer version of the library is available, and update if so. Also consider checking with the library's authors to see if the library is expected to be compatible with Ivy.
3 export declare class MessageService {
~~~~~~~~~~~~~~
node_modules/primeng/api/confirmationservice.d.ts:3:22 - error NG6002: Appears in the NgModule.imports of AppModule, but could not be resolved to an NgModule class.
This likely means that the library (primeng/api) which declares ConfirmationService has not been processed correctly by ngcc, or is not compatible with Angular Ivy. Check if a newer version of the library is available, and update if so. Also consider checking with the library's authors to see
if the library is expected to be compatible with Ivy.
3 export declare class ConfirmationService {
can you please help me and thanks
~~~~~~~~~~~~~~~~~~~
Related
In a React TypeScript project, there are 2 ways we can use Types and Interfaces.
Create and export a type/interface in a file (e.g. FileA) and import it and use it in another file (FileB). for e.g.
// FileA.ts
export interface Foo {
foo: number;
}
//FileB.ts
import {Foo} from ./FileA;
The other approach is we can create a declaration file for e.g. types.d.ts and any interface/type defined in this file is automatically in the whole app and we don't have to import/export those.
The question is which approach is better and should be used? I mean does import/export have a cost attached to it like in the first one?
Thanks
Import/export of types in typescript should have no cost, since it is compiled into js and has nothing to do with performance, bundle size, etc..
While declaring interfaces for the whole project can sound good, it can lead to mess and problems like redeclaring global types with local ones. Especially as your project grows.
I suppose you should try to always use .ts files and import them where you need them.
Use declaration types .d.ts if you need to declare types for .js files, specify types for a module/library, declare types for variables from other scripts, or for files that typescript does not recognize (.env, etc...).
Take a look at official typescript documentation to find out more about .d.ts file usage.
I am using TypeScript with React, and one of the things I want to achieve is background sync for offline support.
To enable typings for service worker, I have to include the WebWorker lib, but it conflicts with DOM lib and produces an error:
(25,1): Definitions of the following identifiers conflict with those in another file:
EventListenerOrEventListenerObject, BlobPart, HeadersInit, BodyInit,
RequestInfo, DOMHighResTimeStamp, PerformanceEntryList, PushMessageDataInit,
VibratePattern, BufferSource, DOMTimeStamp, FormDataEntryValue,
IDBValidKey, MessageEventSource, BinaryType, ClientTypes,
IDBCursorDirection, IDBRequestReadyState, IDBTransactionMode,
NotificationDirection, NotificationPermission, PushEncryptionKeyName,
PushPermissionState, ReferrerPolicy, RequestCache, RequestCredentials,
RequestDestination, RequestMode, RequestRedirect, ResponseType,
ServiceWorkerState, ServiceWorkerUpdateViaCache, VisibilityState,
WorkerType, XMLHttpRequestResponseType
So I am wondering if there is any workaround except for typing most of my arguments any.
You can split your project into multiple parts with separate tsconfig.json files: one part that includes the dom lib and one part that includes the webworker lib. You can make another part for common code that doesn't depend on either library. You can use project references to help automate the build. If this doesn't fully solve the problem, please update the question to describe the outstanding issues.
I'm trying to figure some things related to ES6 modules. How to use namespaces together with angular and typescript.
Assume the following code represents an angular directive. Does anyone know what the module keyword mean and how can you access MyClass in other file.
// file1.ts
module NSpace.Space {
export class MyClass {
constructor() { ... }
...
}
}
I have tried accessing on another file using and re-exporting, however
// file2.ts
import {MyClass} from 'file1';
export {MyClass}
I get this error: error TS2306: File 'file.ts' is not a module
My questions are:
why do I get this?
what is this module keyword?
do we create ES6 modules only based on the directory structure or can
we actually use this notation? module Space.Space1.Space2 ...
From what I've read and experienced so far it seems that ES6 modules are defined based on file structure, that's why I get this error.
I have not written this code, that's why I'm asking. Also it might be useful to mention that I'm using System.JS for importing.
The module keyword in TypeScript caused a bit of confusion, so it is going to be renamed namespace.
Rather than use namespaces, though, you can organise your code by files / file system (which means the actual file location will match the perceived namespace. This is how "exteral modules" (TypeScript) work - and also how ECMAScript 2015 modules work.
So with a quick adjustment, you'll have:
// file1.ts
export class MyClass {
constructor() { ... }
...
}
And then this will work:
import {MyClass} from 'file1';
If you compile targeting ES6, you'll notice that this line of code needs no translation, it matches the standard for module imports. If you target ES5 or lower, TypeScript will transform this statement for you (you can choose the transformation using the --module flag.
I tend to use the UMD compilation option, which means the output will work in web browsers (with RequireJS) or on Node. System JS is actually gaining a lot of traction currently, so you may want to consider that too. Eventually, browsers will simply natively support module loading.
AngularJS allows the use of finally after the return of a promise. However, when I have a grunt-jshint running I keep getting
Expected an identifier and instead saw 'finally' (a reserved word).
Does any one know how to turn this off in jshint?
es5 option
This option enables syntax first defined in the ECMAScript 5.1
specification. This includes allowing reserved keywords as object
properties.
If you are using a version of jshint prior to 2.0.0, then you have the option of setting an es5 flag. Starting with 2.0.0, es5 is the default. I assume you are using an older version.
Alternatively
You can also say promise['finally'](function(){}); rather than promise.finally(function(){});
See
http://jshint.com/docs/options/#es5
https://jslinterrors.com/expected-an-identifier-and-instead-saw-a-a-reserved-word
http://jshint.com/blog/2013-05-07/2-0-0/
Consider I have large library package with sophisticated tree of private or package modules — let's call it funnylib. It's not desirable for enduser to touch internal modules directly (like funnylib.foo, funnylib.bar etc), so I want to provide external interface instead — like this:
funnylib.d:
public import funnylib.foo;
public import funnylib.bar;
public import funnylib.baz;
to be just imported like import funnylib by enduser. The problem is that D disallows having funnylib.d and funnylib/ at the same time.
Is there something like "default package module" in D, like there is __init__.py in Python? If no, what is right way to do design described above?
Update1: I thought about moving iternal modules to package like funnylib_private, so funnylib will import fine, but this will have cost of protection lowering (strongly undesirable), as funnylib will no longer access package protected symbols, and will result in unpleasant file layout.
You cannot have a module and a package with the same name. So, for instance, Phobos couldn't have a std/algorithm.d and a std/algorithm/sorting.d. std/algorithm.d and std/algorithm would conflict. The typical thing to do is what ratchet freak describes and use a module named all which publicly imports all of the modules within that package. But if you want to hide the fact that you're using sub-modules at all, then you could simply do something like
funnylib.d
_funnylib/foo.d
_funnylib/bar.d
_funnylib/baz.d
and not document _funnylib anywhere, but that doesn't work very well with ddoc, because it's going to generate the documentation for each of the _funnylib modules, and the most that it'll generate for funnylib.d is the module documentation, because it doesn't have any symbols to document. The module system is not designed with the idea that you're going to be hiding modules like you're trying to do.
Now, there is currently a proposal under discussion for making it possible to cleanly split up a module into a package when it gets too large (e.g. so that when you split up std.algorithm into std.algorithm.search, std.algorithm.sorting, etc. code which explicitly uses std.algorithm.countUntil won't break even though it's now std.algorithm.search.countUntil). And once that's sorted out, you could use that, but the documentation would still be done for each sub-module, not for your uber-module. It's really meant as a means of transitioning code, not trying to hide the fact that you're splitting up your modules. It's basically just the equivalent of using an all module but with some semantic sugar to avoid breaking code in the case where the package used to be a single module.
create a simple all module with the public imports that is documented to import the library
module funnylib.all;
public import funnylib.foo;
public import funnylib.bar;
public import funnylib.baz;