Repository navigation
Dynamic imports #1
Description
Activity
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.
Reacted by John Henry, Seb Ringrose and Charles LowellI'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.
Reacted by Nano Miratus / Anton Stiglitz, mashaal, John Henry, Seb Ringrose, Craig Doremus, v1rtl, Ahuigo and Yuri Gabriel Ferreira Lisboa@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.
Reacted by John HenryI 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.
Reacted by Sayantan Chaudhuri, Blake Williams, Tom Wieland, John, Kyle June, John Henry, Craig Doremus, zoodogood, Lukas Eibensteiner and LamiHere'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.
Reacted by mashaal, Sayantan Chaudhuri, Eric J. Smith, John Henry and v1rtlNot having dynamic imports prevents this from working: https://github.com/withastro/astro/tree/main/packages/integrations/deno
Reacted by Sayantan Chaudhuri, mashaal, Seb Ringrose, Anthony Williams, v1rtl, Vicary and Maxwell Mapako- added 2 commits that reference this issue
on May 4, 2022 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
GraphQLHTTPfunction whose ONLY change is the dynamic import being changed to non-dynamic. The source is belowimport { 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), }); } } } }; }
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
Reacted by Jayden Seric, Randall Bennett, mashaal, Matthew Wong and Divyansh SinghReacted by Rawk AkaniI'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 thoughdropped 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)Any progress on this? I am hitting this problem too when using
presetWebFontsfrom UnoCSS
It's been over a year. This was the first issue created on this repository. If we were going to get a response, we would've gotten one by now.
Reacted by Brandon SmithReacted by Hen Greville and mashaalHas anyone tried out this ponyfill? It claims to let you import from a string on Deno Deploy.
10 remaining items
- added a commit that references this issue
on May 4, 2023 Goddamnit, there should really be some kind of warning about this when using it in development, even if it's just some CLI warning, Deno already does a great job constantly warning us to not perform anti-patterns. This should be definitely added to avoid us developers wasting so much time developing a feature that will not work on Deno Deploy (if you guys want it to be the defacto choice for Deno websites, that is), but will work just fine everywhere else (like the user above mentioned using Digital Ocean).
I did a whole thing where I created blog posts and would dynamically load them from
[blog]/[post].tsxand now I'll need to create a bunch of individual.tsxfiles instead of just being able to dynamically use them that way.I love the DX, but I'll be damned if the overall (lack of|outdated) documentation doesn't put a damper on my excitement about this runtime.
Reacted by T.J. Crowder and JohnGoddamnit, there should really be some kind of warning about this when using it in development, even if it's just some CLI warning, Deno already does a great job constantly warning us to not perform anti-patterns. This should be definitely added to avoid us developers wasting so much time developing a feature that will not work on Deno Deploy (if you guys want it to be the defacto choice for Deno websites, that is), but will work just fine everywhere else (like the user above mentioned using Digital Ocean).
I did a whole thing where I created blog posts and would dynamically load them from
[blog]/[post].tsxand now I'll need to create a bunch of individual.tsxfiles instead of just being able to dynamically use them that way.I love the DX, but I'll be damned if the overall (lack of|outdated) documentation doesn't put a damper on my excitement about this runtime.
Tell me about it. Compare https://github.com/BrunoBernardino/deno-boilerplate-simple-website/blob/main/routes.ts#L43-L44 (what's needed if Deno Deploy supported it):
// NOTE: Use this instead once https://github.com/denoland/deploy_feedback/issues/1 is closed // const { pageContent } = await import(`./pages/${id}.ts`);
vs https://github.com/BrunoBernardino/deno-boilerplate-simple-website/blob/main/routes.ts#L10-L24 (what's necessary for it to work on Deno Deploy):
// NOTE: This won't be necessary once https://github.com/denoland/deploy_feedback/issues/1 is closed import * as indexPage from './pages/index.ts'; import * as ssrPage from './pages/ssr.ts'; import * as dynamicPage from './pages/dynamic.ts'; import * as formPage from './pages/form.ts'; import * as webComponentPage from './pages/web-component.ts'; import * as reactPage from './pages/react.tsx'; const pages = { index: indexPage, ssr: ssrPage, dynamic: dynamicPage, form: formPage, webComponent: webComponentPage, react: reactPage, };
Reacted by Yuri Gabriel Ferreira LisboaThis is a show stopper for using MDX on Deno Deploy without introducing a build step, which is a shame.
Reacted by Rawk AkaniWhat I was surprised at is that Fresh states it has “No build step”, but actually it does a build internally. It's just hidden behind some UX design while development, but if one wants to track the project by Git (necessarily!), they has to be aware of this fact, as noticed in the generated
fresh.gen.ts:// DO NOT EDIT. This file is generated by fresh. // This file SHOULD be checked into source version control. // This file is automatically updated during development when running `dev.ts`.It's okay for me, but feels like this could introduce chances of deployment failure, like forgetting to regenerate
fresh.gen.tswhen adding/removing new routes. Hopefully I would like to see Deno Deploy supports dynamic imports. Any kind of filesystem-based routing framework would be happy with it.Reacted by lionel-rowe- added 2 commits that reference this issue
on Jun 22, 2023 This is now supported https://deno.com/deploy/changelog#statically-analyzable-dynamic-imports
Reacted by bitn00b, Andy Jiang, Oleh Martsokha, Rawk Akani, Sʜɪᴍᴜʀᴀ Yū, Jerry Green, Daniel Salvadori, Vicary, Brett Chalupa and mashaalReacted by Roy Ivy IIIReacted by lionel-rowe and Jerry GreenReacted by Tom WielandThis is a great feature! Now the sky is the limit =)
Actually only statically analyzable doesn't solve my use case :/
Reacted by Mark Judy, Bruno Bernardino, Yuri Gabriel Ferreira Lisboa, Gabriel Francisco, Sayantan Chaudhuri, Roy Ivy III, Julien Delort, Josh Gum and Scott PruttonThis doesn't help my use case either. If the issue is considered complete now, I'm glad that I've pivoted to another method of fetching my files, but it would have sucked if I had waited for this.
Reacted by Bruno Bernardino and Roy Ivy IIIReacted by KinThis is a show stopper for using MDX on Deno Deploy without introducing a build step, which is a shame.
It turn's out I was wrong here. You can use MDX without a build step on deno deploy. For any other MDX users who come across this, it supports an
evaluate()method which will compile the MDX dynamically andeval()it. (eval caveats apply!)You can't do static imports inside your MDX, but you can just do static imports inside your JS code and then pass those values down into the mdx scope.
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.