Consider node_modules in /assets

[jsonmaur]

The ESBuild Javascript pipeline no longer resolves dependencies from the node_modules folder if it's located at assets/node_modules. This is new behavior from a recent release, either v0.78 or v0.78.1. Previously-working builds now result in JSBUILD: failed to transform...Could not resolve "foobar".

I was able to fix this by creating a jsconfig.json at the root of the project with the following:

{
	"compilerOptions": {
		"baseUrl": "assets",
		"paths": {
			"*": ["node_modules/*"]
		}
	}
}

However, this is not well-documented anywhere, either in Hugo or ESBuild.

---

Another strange behavior: If a Javascript file is importing another local file, assets/jsconfig.json is automatically created with the following, which doesn't seem to be necessary:

{
 "compilerOptions": {
  "baseUrl": ".",
  "paths": {
   "*": [
    "*"
   ]
  }
 }
}

When I delete this file, it shows right back up on hugo serve. If creating jsconfig.json at the root of the project solves the above issue, there doesn't seem to be a need to have this redundant file automatically created in the project.

---

Reproduction Repo

What version of Hugo are you using?

Hugo Static Site Generator v0.78.2/extended darwin/amd64

[bep]

This was not an intentional break, but it's hard to guess everyones setup.

I have thought long and hard about node_modules and package.json etc. vs Hugo and to me it does not make sense to put node_modules inside /assets. That folder is where you mount your own files, not dependencies.

So, in short, with Hugo 0.78.2 we expect in general that:

• node_modules lives in the project directory
• there is a recent hugo mod npm pack command that is added to help merging dependencies from imported Hugo Modules
• Imports from files outside /assets will be handed to ESBbuild's resolver with the project dir as the resolve directory.

So, as to this particular issue, I don't think I could support (in a simple fashion) it even if I wanted to (and I would need some more convincing arguments).

[jsonmaur]

Understood. I was under the impression this was the default project layout, since layout files resolve from the assets directory. It would make sense that if <script src="js/main.js"></script> resolves to assets/js/main.js, then import "./foobar" should resolve to assets/js/foobar.js, and import "foobar" should resolve to assets/node_modules/foobar. I think the main issue here is consistency and documentation.

Also, I'm assuming the jsconfig.json is coming from ESBuild? I'd like to know how to prevent it from appearing in the assets directory automatically, or if that's an issue that needs to be brought up in the ESBuild repo.

[bep]

As to jsconfig.json in /assets. That comes from Hugo (motivated by intellisense, incredibly useful in multi-module setups), you can turn it off:

https://gohugo.io/getting-started/configuration/#configure-build

The asstets directory is for Hugo assets. Third party NPM dependencies does not fall into that category (in my head). node_modules lives in the folder where package.json lives, and you wouldn't put that into /assets, would you?

I guess it could make sense to allow /assets/node_modules for the project directory (if someone could argue a use case not currently possible), but that would not work for a theme/module, as it would be impossible for the project to control/know which JS dependencies were in play.

I'll keep this issue open for discsussion.

[jsonmaur]

Oh excellent, didn't realize there was a config option to disable it. Mind if I make a small PR to add that to the Javascript pipeline docs? It's a good thing to be aware of for those of us who don't use intellisense.

To answer your question, yes I was putting package.json into the assets dir while using npm install --prefix assets. My reasoning for this was because the NPM dependencies are used by files inside the assets dir exclusively, so I didn't see a reason for keeping them one level higher in the filesystem. I would expect the assets directory to be self-contained with everything required to build the final assets.

That being said, I didn't consider how using a theme could complicate this setup. I see where you're coming from. Since my specific use-case can be solved by putting a jsconfig.json at the project root as noted above, this isn't a blocking issue by any means.

[jsonmaur]

Nevermind on the PR suggestion... noticed that it's already in the documentation and my tired brain just missed it. My mistake. Thanks for your time @bep.