brunch / brunch

:fork_and_knife: Web applications made easy. Since 2011.
https://brunch.io
MIT License
6.81k stars 436 forks source link

Directory structure handled incorrectly in new project. #1890

Open seanmorris opened 1 year ago

seanmorris commented 1 year ago

Description

The assets directory is not being handled correctly in a new project.

Expected behavior

The index.html file should be built to the public/ directory.

Actual behavior

The index.html file is built to the public/assets/ directory.

Environment

  1. Brunch Version: 4.0.1
  2. Node.js Version: 19.2.0
  3. NPM Version: 8.19.3
  4. Operating system: Debian GNU/Linux 11 Kernel 5.10.0-19-amd64

package.json contents

{
  "name": "brunch-app",
  "description": "Brunch.io application",
  "private": true,
  "author": "Brunch",
  "version": "0.0.1",
  "repository": "",
  "scripts": {
    "start": "brunch watch --server",
    "build": "brunch build --production"
  },
  "dependencies": {},
  "devDependencies": {
    "auto-reload-brunch": "^2",
    "brunch": "^4",
    "clean-css-brunch": "^3",
    "terser-brunch": "^4"
  }
}

brunch config contents

none

seanmorris commented 1 year ago

Working Lockfile: https://pastebin.com/UuipAhAK Broken Lockfile: https://pastebin.com/z1iYS1ck

seanmorris commented 1 year ago

It seems to be a bug with the new way strings are handled in anymatch 3.1.3. On line 50 of index.js, false is now provided as the second parameter to normalizePath().

https://github.com/micromatch/anymatch/blob/master/index.js#L50

Adding the following values to the root level package.json corrects the issue:

Note that npm install must be run explicitly if node_modules does not exists yet.

{
  "overrides": {
    "brunch": {"anymatch": "3.1.2"},
    ".": {"anymatch": "3.1.2"}
  }
}
seanmorris commented 1 year ago

I've found the issue, submitted a patch, and alerted the maintainers of the dependency to watch their semver. https://github.com/brunch/brunch/pull/1891 https://github.com/micromatch/anymatch/issues/51

psagers commented 1 year ago

It's worth noting here that a workaround was committed in a20d6a2997da1a192bed80f6d1f3fc2815196692 and released in 4.0.2 (Jan 10).