--incremental passthrough copy ignores folder structure

[anghelos]

Possibly related to #1299 and #2182 When running eleventy (v2.0.0-canary.4) with the --incremental flag, modified passthrough files are copied to the target directory without keeping any subfolders.

Example: With this passthrough rule,

  eleventyConfig.addPassthroughCopy({ "_includes/assets/": "assets" });

A modified file that was in _includes/assets/css/ will be copied directly to assets/ (without the css subfolder).

Expected behavior _includes/assets/css/style.css should be copied to /assets/css/style.css and not /assets/style.css

Environment:

• Windows 11
• v2.0.0-canary.4

[zachleat]

Hmm, I believe this is by design? The traditional single argument usage maintains directory structure https://www.11ty.dev/docs/copy/#configuration-api-method but changing the output directory does not.

You can use eleventyConfig.addPassthroughCopy({ "_includes/assets/css/": "assets/css/" }); to workaround this

[zachleat]

For later me, I originally thought this was related to #2278 (but no)

[zachleat]

This is an automated message to let you know that a helpful response was posted to your issue and for the health of the repository issue tracker the issue will be closed. This is to help alleviate issues hanging open waiting for a response from the original poster.

If the response works to solve your problem—great! But if you’re still having problems, do not let the issue’s closing deter you if you have additional questions! Post another comment and we will reopen the issue. Thanks!

[anghelos]

Why the inconsistency with the default build behavior though?

I'd need to test this again to see how/if it has evolved since, but when I opened the issue, the folder structure was copied over on a regular build, and even with the --serve flag when not using --incremental.

[anghelos]

Even when using the --incremental flag, the first build follows the folder structure, but updated (watched) files subsequently ignore it. (tested on v2.0.0-canary.11)

[anghelos]

I guess this is irrelevant now that v2.0.0-canary.12 introduced emulated passthrough copy.

[zachleat]

Yeah, kinda! I did review the code that fixed #2278 and found another inconsistency that was fixed as part of #1038—so either way if you really want to test you can use the escape hatch to opt-out of emulated passthrough copy https://github.com/11ty/eleventy/commit/b8076f3c877e5e31fedf027050f866fb29e773c3

[jgerigmeyer]

This does strike me as a bug, and is not documented in a way that makes it clear as an intentional choice. My use-case is wanting to passthrough copy with an incremental build, changing the output directory but maintaining the subdirectory structure. On initial build this works fine with e.g. addPassthroughCopy({ _built: 'assets' }), and a file like _built/css/site.css is copied to _site/assets/css/site.css. But then when the input file is changed, the dev server copies it directly to _site/assets/site.css -- which breaks the site. If it's an intentional choice not to support changing the output directory while retaining the source subdirectory structure, why do that on a full build?

In my case I need to support arbitrary subdirectory names, so adding individual addPassthroughCopy() for each subdirectory is not practical. In the meantime I can try setServerPassthroughCopyBehavior('passthrough'), but it's unfortunate if emulated passthrough copy is the only way to support this.

[anghelos]

A (pretty late) update: This still doesn't work, even with emulated passthrough copy. The only workaround I've found for now, if I want to be able to modify CSS files and see the results, is to place my css file in a separate folder, then copy them to the assets folder:

eleventyConfig.addPassthroughCopy({ "_includes/assets/": "assets" });
eleventyConfig.addPassthroughCopy({ "_includes/css/": "assets/css/" });

This still feels like a bug.