Changes in dependencies to your Eleventy config file don’t cause the config file to be reloaded

[dephiros]

Is your feature request related to a problem? Please describe.
When a shortcode is defined in an external files and being require into .eleventy.js, modifying the shortcode will not reload the site

Reproduce steps:

• Clone https://github.com/dephiros/11ty-tailwind/ and checkout 11ty-require-reload
• Do yarn && yarn serve
• Open the browser, notice TEST and TEST REQUIRE
• Open .eleventy.js and modify Test shortcode, notice the browser will reload with the new change
• Open _11ty/Test.js and change some text, notice the terminal is showing reload but the browser does not reflect the change

Describe the solution you'd like
Change in code that is required by .eleventy.js should reflect in the browser

Describe alternatives you've considered
I saw the issues mentioned in #325 but it does not fix for me even with watch target. The shortcodes is still cached and require restarting the server

[chasemccoy]

Also seeing this issue and spent waaayyyy too long trying to figure it out.

[chasemccoy]

This is labelled as an enhancement, but I think it might be better considered a bug?

[dephiros]

This is labelled as an enhancement, but I think it might be better considered a bug?

I was thinking that after creating the ticket too but not sure how to change it

[chasemccoy]

@zachleat could you help us get this labelled as a bug? (or give some guidance on whether it is a bug or expected behavior)

[reubenlillie]

I cannot speak for @zachleat, but I've come to see this as "expected" behavior. It's akin to modifying the .eleventy.js file itself, which also requires an explicit call to rebuild/serve. If I'm not mistaken, it has more to do with how BrowserSync treats configuration files than it does with Eleventy proper.

[chasemccoy]

@reubenlillie Hmm... I guess it seems different to me than modifying the .eleventy.js file because that file is purely for configuration, whereas shortcodes are actually producing markup (more like a template file in my eyes). I appreciate the context though! If this is expected behavior I can certainly work around it.

[reubenlillie]

@chasemccoy, right. Even though shortcodes, filters, and so forth can reside in separate modules that you pass eleventyConfig, ultimately, they are all registered via .eleventy.js. That's why those changes require the hard reload. Separate files or not, you're technically modifying the configuration either way.

[chasemccoy]

That makes a lot of sense. Thanks @reubenlillie!

[ghost]

It's akin to modifying the .eleventy.js file itself, which also requires an explicit call to rebuild/serve.

Actually, there is a config reset in watch mode, which is (only) triggered if .eleventy.js is modified (which was added in this commit: 09973ae).

I first thought, an easy workaround could be using the beforeWatch event to trigger a change event on .eleventy.js if there is a change in additonal imported config files, to trigger the built-in config reset. But this way the build would run twice, since there is no way to cancel the build from the beforeWatch event. So i ended up running my own chokidar instance for the files imported in .eleventy.js and trigger a change event on .eleventy.js from there. This feels very hacky, but still better than restarting the watch build on every change. 🙈

So a built-in way could perhaps be, to provide an option like addConfigResetGlob to have the option to configure additonal files that would trigger a config reset. 11ty watches these files automatically already (just static imports, not dynamic imports), but there is no config reset during watch for them.

@zachleat What do you think? Are there any disadvantages in providing something like this?

[zachleat]

Sorry to chime in super late here, y’all. This is indeed a bug. The goal is to not require re-starting the dev server (ever). But we have some work to get there, I think.

@jens-t Desired behavior would be that if a dependency of the config file changes it would reload the config, see https://www.11ty.dev/docs/watch-serve/#watch-javascript-dependencies I don’t think we need to add extra APIs here since we know the dependencies?

[ghost]

@zachleat The dependencies are not known for dynamic imports. Or maybe just not in my usecase?

I build an autoloader for my 11ty projects, so that all i have to do, is to create new files to add filter, shortcodes, transforms, tags and collections. This autoloader uses dynamic imports.

Example code for the autoloader:

const initAutoload = conf => {
  const typeMapping = [
    {
      type: 'filter',
      extension: 'js',
      method: 'addFilter'
    },
    {
      type: 'tags',
      extension: 'js',
      method: 'addNunjucksTag'
    },
    {
      type: 'collections',
      extension: 'js',
      method: 'addCollection'
    },
    {
      type: 'shortcodes',
      extension: 'js',
      method: (name, content) => {
        if (!content.paired || content.paired !== true) {
          (!content.async || content.async !== true)
            ? conf.addNunjucksShortcode(name, content.shortcode)
            : conf.addNunjucksAsyncShortcode(name, content.shortcode);
        }
        else {
          (!content.async || content.async !== true)
            ? conf.addPairedNunjucksShortcode(name, content.shortcode)
            : conf.addPairedNunjucksAsyncShortcode(name, content.shortcode);
        }
      }
    },
    {
      type: 'transforms',
      extension: 'js',
      method: 'addTransform'
    }
  ];

  const initType = data => {
    const files = path.resolve(conf11ty.paths[data.type]) + '/**/*.' + data.extension;
    glob.sync(files).forEach(file => {
      const name = path.parse(file).name;
      const content = require(file);
      typeof data.method === 'function'
        ? data.method(name, content)
        : conf[data.method](name, content);
    });
  };

  typeMapping.forEach(initType);
};

[coryrylan]

I think this is related. I import JS files from a separate directory to use in my *.11ty.js templates. Adding the files via addWatchTarget will trigger a reload but the import/required files are cached by node so the browser refreshes but the updates are not applied.

It looks like you can work around this by using the decache package and hook into the eleventy.beforeWatch event to remove it from the cache. This seems to allow me to edit the imported file and see the changes reflected in the browser without restarting the dev-server.

I use the esm package but this should work with require statements as well I think.

// .eleventy.js
import decache from 'decache';

export default function (config) {
  config.addWatchTarget('../examples/**/*.js');

  config.on('eleventy.beforeWatch', async (files) => {
    files.forEach(file => decache(file));
  });

  ...
}

[zachleat]

Circling back here, this might get fixed with #2147, shipped with 2.0.0-canary.5.

Can anyone confirm or deny?

[zachleat]

I can confirm the specific issue of modifying the dependency file is still present.

The first hurdle to cover here is that .eleventyignore has the _11ty folder, which them prevents files in that folder from being watched. I’ll fix that in upstream eleventy-base-blog.

Update this was fixed awhile back 11ty/eleventy-base-blog@75e71ad

As for the shortcode updates, stay tuned

[zachleat]

The fix for this will ship with 2.0.0-canary.11

[notacouch]

Is anyone getting this issue in 11ty 3? I'm on alpha 5, I'm using JavaScript components in a nested _src directory, e.g. in .eleventy.js:

import HeaderNav from './_src/components/global/HeaderNav.js';

export default function (eleventyConfig) {
  eleventyConfig.addShortcode('HeaderNav', function HeaderNavShortcode(currentPageUrl) {
    return new HeaderNav().render(currentPageUrl);
  });

  // The below makes no difference. Components changes are not reflected on refresh.
  // eleventyConfig.setServerOptions({
  //   watch: ['_src/components/**/*.js'],
  // });
}

Changes to HeaderNav trigger a refresh but the actual changes are not reflected unless I kill the server and start it up again. I should probably make a new issue for this if I can replicate.

[jens-struct]

@notacouch Please see #3270 for a possible workaround.