Dynamic imports

[newtack]

I know this is not supported today, but would love to see this being supported in the future.

Use case: We have a dynamic server rendered web server where we use configuration and dynamic imports based on that configuration to fetch the relevant page handler.

[WardCunningham]

Federated wiki uses dynamic imports for rarely used or newly created item formatting plugins. We haven't yet figured out exactly how Deploy helps us, perhaps as insolation from older or non-compliant browsers. We usually stop thinking these things when we remember we can't load plugins.

[Industrial]

I'm trying to get https://github.com/exhibitionist-digital/ultra deployed (react 18, streaming SSR) but after forking it and removing the import maps I found that it uses dynamic imports, so it's currently not possible to deploy with.

[nnmrts]

@Industrial Same...I don't really see the reason for dynamic import being disabled, but I'm also not a backend expert.

I tried a lot of things but I eventually gave up and now use a DigitalOcean Droplet...but a Deno Deploy solution would be really awesome, not just because of the money I now have to pay for DO, but because Deno Deploy is so easy and fast to work with.

[mashaal]

I can see why dynamic imports of remote libs may be unwanted, but there is a lot of value in the ability to dynamically import local modules. Modern frontend frameworks could then have native code-splitting -- importing route and component files as needed, like @newtack explained above.

Libraries like React and Solid are now supporting dynamic imports. It currently does work in Deno when server side rendering, so I imagine we will be seeing more of this in the near future: https://reactjs.org/docs/code-splitting.html#reactlazy

Maybe we could declare all remote libs in an importmap -- then only allow local modules to be imported?

@Industrial I did push and update to https://github.com/exhibitionist-digital/ultra which allows deployment to Deno Deploy, but yes, you need to ensure you don't actually use dynamic imports in your codebase.

[BrunoBernardino]

Here's an example similar to the situation as OP that doesn't work right now in Deno Deploy: https://github.com/BrunoBernardino/deno-boilerplate-simple-website/blob/5d32fb081d6080564e91a8ca8fdd6921ab9420cc/routes.ts#L31-L35

This means the alternative is to load all pages even if they're not going to be needed, so that it works in Deno Deploy: https://github.com/BrunoBernardino/deno-boilerplate-simple-website/blob/5d32fb081d6080564e91a8ca8fdd6921ab9420cc/routes.ts#L4-L12

Not having this functionality means it'll be impossible for any similar performance logic to be used with Deno Deploy, which seems like a shame.

[johnhenry]

Not having dynamic imports prevents this from working: https://github.com/withastro/astro/tree/main/packages/integrations/deno

[ayoreis]

I'm building an web library (imagine React but 100× better) but would need Dynamic imports for async importing of data URLs. Of course works in Deno, but I would also like it to deployable to Deno Deploy. Would be great if you'd add this! Thanks.

[Wolven531]

For those that land here from GQL (https://doc.deno.land/https://deno.land/x/gql@1.1.1/mod.ts or https://deno.land/x/gql@1.1.1), to avoid using the dynamic import in this module, I created a local version of the GraphQLHTTP function whose ONLY change is the dynamic import being changed to non-dynamic. The source is below

import {
	GQLOptions,
	runHttpQuery,
} from 'https://deno.land/x/gql@1.1.1/common.ts';
import { renderPlaygroundPage } from 'https://deno.land/x/gql@1.1.1/graphiql/render.ts';
import type { GQLRequest } from 'https://deno.land/x/gql@1.1.1/types.ts';

// !!! all code below is from https://deno.land/x/gql@1.1.1/http.ts
// except for removal of dynamic import

/**
 * Create a new GraphQL HTTP middleware with schema, context etc
 * @param {GQLOptions} options
 *
 * @example
 * ```ts
 * const graphql = await GraphQLHTTP({ schema })
 *
 * for await (const req of s) graphql(req)
 * ```
 */
export function GraphQLHTTP<
	Req extends GQLRequest = GQLRequest,
	Ctx extends { request: Req } = { request: Req },
>({
	playgroundOptions = {},
	headers = {},
	...options
}: GQLOptions<Ctx, Req>) {
	return async (request: Req) => {
		if (options.graphiql && request.method === 'GET') {
			if (request.headers.get('Accept')?.includes('text/html')) {
				// !!! only modified portion is here
				// const { renderPlaygroundPage } = await import(
				// 	"./graphiql/render.ts"
				// );
				// !!! end of modified portion
				const playground = renderPlaygroundPage({
					...playgroundOptions,
					endpoint: '/graphql',
				});

				return new Response(playground, {
					headers: new Headers({
						'Content-Type': 'text/html',
						...headers,
					}),
				});
			} else {
				return new Response(
					'"Accept" header value must include text/html',
					{
						status: 400,

						headers: new Headers(headers),
					},
				);
			}
		} else {
			if (!['PUT', 'POST', 'PATCH'].includes(request.method)) {
				return new Response('Method Not Allowed', {
					status: 405,
					headers: new Headers(headers),
				});
			} else {
				try {
					const result = await runHttpQuery<Req, Ctx>(
						await request.json(),
						options,
						{ request },
					);

					return new Response(JSON.stringify(result, null, 2), {
						status: 200,
						headers: new Headers({
							'Content-Type': 'application/json',
							...headers,
						}),
					});
				} catch (e) {
					console.error(e);
					return new Response('Malformed request body', {
						status: 400,
						headers: new Headers(headers),
					});
				}
			}
		}
	};
}

[brundonsmith]

Any movement on this? It's keeping me from using Deno Deploy for a project

---

Edit: I came up with a workaround; I'll share it here for others that may be stuck.

My situation is one where I didn't strictly need dynamic imports (the modules to be imported all exist in source control), I just wanted to import them dynamically for ergonomics; when I add a new file in a certain directory, I want it to be picked up without going and manually configuring it to be loaded.

What I did as a workaround is I wrote a script to walk that directory and generate a TypeScript file that statically imports all the relevant modules, and re-exports their contents in a way where they can be looked up by module path. This manifest is then checked into source control, so by the time it gets to Deno Deploy everything is static. Hopefully I'll be able to drop this mechanism one day.

You can see it here: https://github.com/brundonsmith/site/blob/master/routes-manifest-generate.ts

[orta]

I'm hitting this because I need to set up a bunch of node-y / browser-y globals before my app's code is loaded due to a library not supporting deno - Azure/azure-sdk-for-js#13281 (comment) (gonna look into getting this uncoupled though dropped the dep by re-creating it in fetch myself, leaving the comment because it is still a legit case for why you might need the dynamic import)