Extract core (no dev server, no chokidar) class from Eleventy.js

[zachleat]

Currently src/Eleventy.js also includes extra dependencies for --watch (chokidar) and --serve (@11ty/eleventy-dev-server) but it’d be nice to have a src/Core.js that doesn’t use these features.

This would simplify using Eleventy clientside and bundling for serverless too.

[zachleat]

Marginally related to #3652.

Not really related to #3647 but worth cross-linking.

[darthmall]

Sorry, this isn’t the best place for this, but I’ve seen occasional comments here and there about running Eleventy client-side, but I haven’t been able to find any issues discussing it. Is there such an issue? I’m perplexed by why running in a browser would be a goal for a static site generator.

[zachleat]

@darthmall sorry for being a bit cryptic on that point, the most practical short term benefit is the demo runner on the docs https://www.11ty.dev/#try-eleventy-in-your-browser and right now in use on the permalink docs: https://www.11ty.dev/docs/permalinks/

but definitely some bigger idea things to come there too (which I am just teasing for now, sorry!)

[dwkns]

@darthmall In theory it adds the ability to do live previews in CMS too.

[jeremenichelli]

@dwkns I was thinking of that exactly too. One question @zachleat will the Eleventy class allow to build only an specific path to speed up the run on a serverless function? Something like:

const { Eleventy } from '@11ty/eleventy'

async function handler({ req }) {
  const eleventy = new Eleventy()
  const page = eleventy.toString({ path: req.path })
  
  return {
    statusCode: 200,
    body: JSON.stringify({
      data: page
    })
  }
}

Haven't seen any reference on how these serverless flow would work, but being able to build only one page would make the function run way faster.

[zachleat]

for sure we already have support for passing an incremental file in to the build documented in the CLI, if you want to follow how that works from cmd.cjs: https://www.11ty.dev/docs/usage/#incremental-for-partial-incremental-builds

https://github.com/11ty/eleventy/blob/2b5e72c5fbea41bd82a03472679d90ef75fc3119/cmd.cjs#L107-L108

[jeremenichelli]

Oh interesting, don't know if there's a correlation between them but, does elev.setIncrementalFile means that I can do this?

const eleventy =  new Eleventy()
eleventy.setIncrementalFile('...')
eleventy.toJSON()

It would be really cool, and should probably be documented, I don't see this on the Programmatic API page.

Another thing is, I think developers would prefer to pass the resulting slug. I know this is actually super hard to achieve since you might actually need to do a dry run to get all permalinks but avoid the build, detect the source file and generate the only page. This will allow suepr efficient full serverless sites plus previews for CMS based projects.

const eleventy =  new Eleventy()
eleventy.setIncrementalSlug('/about')

const [ page ] = eleventy.toJSON()
// or if we return only the page object, const page = eleventy.toJSON()

The issue with passing the file to generate the JSON is, if that said file uses the Pagination API, and the collection it iterates is really big, it would build tons of pages, to display just one. I don't see it as optimal, plus there's some lifting the developer has to do to extract the slug, etc.

@zachleat let me know if there's an existing issue about this, or if you want me to open a new issue, don't want to create more noise on the repository.

[dwkns]

@jeremenichelli with respect to passing the slug, you can probably do this already (albeit with a workaround).

In eleventy.after you get a results array which contains inputPath and url. You could use this to create a .js file in your project with look up table mapping your URL's to the templates used to create them. This file could be passThroughCoppied into your CMS preview code each time your site builds/deploys. It would make it trivial (and fast) for your preview/serverless code to know which template to use when you passed it a url.

[jeremenichelli]

@dwkns it is true that finding the content file that matches the slug is extra work, but completely doable. IF Eleventy offered that, it would probably fo exactly that, generate a file that maps both.

The thing that is more important and not resolved is that, still even with this, if my page is behind a large collection generated via Pagination API I would need to build all pages to extract that one. Probably over defensive to care about this, and not a blocker, but something that I think the engine could solve. But yes, the slug <-> conte tfile mapping is not a blocker.