Open kfranqueiro opened 5 years ago
One thing to consider instead of passing {}
into MDCFoundation<{}>
is to pass in a generic instead. Of course there is always the gross escape hatch of MDCFoundation<any>
which may or may not matter since you would just be saying its a foundation that accepts anything as an adapter
Hello, gentle Bump on this issue
Even though the tsconfig parameter noStrictGenericChecks is set to true:
"compilerOptions": {
"target": "es6",
"module": "es2015",
"lib": [ "es6", "dom" ],
"allowJs": true,
"noStrictGenericChecks": true,
"experimentalDecorators": true,
"baseUrl": ".",
"moduleResolution": "node",
"allowSyntheticDefaultImports": true, /* Allow default imports from modules with no default export. This does not affect code emit, just typechecking. */
"esModuleInterop": true, /* Enables emit interoperability between CommonJS and ES Modules via creation of namespace objects for all imports. Implies 'allowSyntheticDefaultImports'. */
"jsx": "react",
"sourceMap": true,
"strict": true,
"noImplicitAny": false,
"types": [ "webpack-env" ]
}
In the meantime I am using an old version( 0.39.1)
Is there any workaround for this issue yet ? Setting "noStrictGenericChecks" to true does not work for me. I'm using version 0.44.1 in my Angular/TypeScript project for now as it's the last version that does not have this issue.
While reviewing #4481 this morning, I finally realized what was preventing us from seeing the errors James encountered in #4463.
noStrictGenericChecks: true
is one of the tsconfig settings we inherited while trying to mirror our internal tsconfig as closely as possible. If I remove that setting, we see errors very similar to, if not exactly like, what James was seeing. For example:James has some suggestions on how to fix this, but I'm wondering if we can fix it without needing to e.g. make
adapter_
public on foundations...