desmap

> How it gonna prevent into bundling the whole graphql-js library then? dynamic imports? > Create a common/typegraphql.ts file where you do the logic behind the env variable This is...

No I just realize that dynamic import need to package the whole dir... ok, then there might be no solution??

> How then you gonna be able to import something like decorator from such entrypoint? What do you mean with this?

> You can't do that in the runtime based on the env variable value. Ok, makes sense. The we can close this issue because my proposed solution is actually crap....

Don't want to go to deep: - For Next.js I need also to declare at runtime because Next runs it own backend server (which I don't use as my real...

When I remember it right, I couldn't alias the shim with TS' references features at all (depending on the consuming package), so yeah

again re my initial idea with dynamic imports: eg Parcel does have zero configuration code splitting using dynamic import() statements. So would code splitting not help at runtime, so the...

> Go ahead, figure it out https://github.com/desmap/type-graphql-fix-shim-example > clear and simple solution We even don't need dynamic imports, just a small mod of your `browser-shim.ts` is required => https://github.com/desmap/type-graphql-fix-shim-example/blob/master/fix-tgql/src/index.ts So...

Ok busy man, here my PR https://github.com/MichalLytek/type-graphql/pull/674

a nice side effect with that PR: we can replace the current shim documentation to four words: *enable shim with `TYPE_GRAPHQL_SHIM=1`* Isn't this a great UX?! :)