Benefit of using Hugo modules over node modules

Hi there,

Why should one use Hugo module over the traditional way of node module?

Are there any added benefits when working in Hugo. I can import git repositories etc but just a comparison to the traditional way what are the benefits of Hugo modules vs node modules in Hugo.


I find alot about how to use it but cant understand why should I use it instead of traditional node module

thanks

1 Like

For me the list is long (and longer than this, probably):

  1. I don’t like NPM, so I like to avoid it whenever I can. It’s plenty of examples where their current dependency scheme breaks or does unexpected things (example: Dev corrupts NPM libs 'colors' and 'faker' breaking thousands of apps)
  2. NPM only supports modules published to a NPM registry (you can not depend on a repo/folder on, say GitHub).
  3. A little related to 1, but Go Module’s Minimal Version Selection makes a lot more sense to me than the NPM way of doing it. Also related is Go Module’s built-in security which I consider superior to NPM.
  4. You get a much better Hugo integration; configure your dependencies and mount folders etc. inside config.toml. List your dependencies (command line and in the templates).
  5. You can vendor Hugo Modules and get a project that can be run without network (I guess you can do similar by committing node_modules to Git, but …)
  6. … To be continued. I will add some later when I get some time.
5 Likes

thanks @bep for taking the time

I realise some benefits but wasn’t sure of how exactly it is better than the node modules. if you can please share the rest it will be really helpful to me and other beginners to understand and compare the benefits and why we should let go the method we normally use.

looking forward to the rest of the benefits of Hugo modules

thanks again

1 Like

point 1 noted the security against when someone goes mental and intentionally introduce code which break functionality 4.4 million users of color.js alone.

1 main benefit is higher control and security of my project against npm breaks

this is really great in situation where I am waiting for more than an year for the version to be released on npm

2nd main benefit I can quickly add the latest version without having to wait months and years for npm release

Yea, but the main reason I think this is valuable (and probably the most valuable thing) is that it broadens the “dependency definition”.

To me, an NPM dependency is “code” (aka JavaScript, CSS)

But an Hugo Module is that, too, but it’s also content, images etc.

I have no clue how to publish something to the NPM registry, and I don’t care to learn. Being able to just depend on a GitHub project has tremendous value for me; it’s what I use for everything and I certainly do not want to do this double bookkeeping/releases with NPM …

But NPM is very much the defactor standard for many things, so there are situations where you don’t get around it in Hugo … But I try. I have been toying with the idea of creating this “Hugo Module NPM Adapter” …

Also, not being able (or wanting to) pull in JS dependencies from NPM does make you think twice before adding some tiny little library for some string manipulation – often it’s the best thing to just write that function yourself.

3 Likes

point noted, I have to do more demo work to see how it work for me.

I suppose this might be the one reason “double work” for many outdated npm packages. this is really revolutionary for me coming from nextjs as there are many outdated packages which I can’t do anything about but wait for npm release or write manually.

I see now with Hugo module how easily I can add the updated version directly from GitHub in my Hugo project. I try with the v5 of photoswipe which is still in beta :joy: not something I will be doing anytime soon with traditional method.

To be fair, one can use npm with both public and private repositories, regardless of whether they contain code or content.

Feel free to try it with this test repository:

npm install https://github.com/jmooring/hugo-content

Then add this to your site config:

[[module.mounts]]
source = 'content'
target = 'content'
[[module.mounts]]
source = 'node_modules/hugo-content'
target = 'content'

The source repository needs a package.json file, created with npm init -y.

4 Likes

Dear @jmooring thanks for sharing this info

I read about this in Hugo docs but I was wondering since Hugo modules does the same thing(according to my beginner knowledge) why it exist and learn more about in which ways it is better then the traditional method.

Since I am migrating some nextjs projects to Hugo I am also trying to get rid of the node/nextjs/npm way of things because what I realise with Hugo is the ease and minimal exported files and folders comparing to nextjs static export here is an example of default static export.

Nextjs Hugo
1 _next/jqkr…/ categoreis/index.xml
2 _next/static/chunks/pages/_app-9c…js tags/index.xml
3 _next/static/chunks/pages/_error-22…js index.xml
4 _next/static/chunks/pages/_index-3b…js sitemap.xml
5 _next/static/chunks/framework-6e…js
6 _next/static/chunks/main-101…js
7 _next/static/chunks/polyfills-5c…js
8 _next/static/chunks/webpack-69b…js
9 _next/static/css/27d…css
10 _next/static/css/149…css
11 _next/static/jqkr…/_buildManifest.js
12 _next/static/jqkr…/_middlewareManifest.js
13 _next/static/jqkr…/_ssgManifest.js
14 _next/404.html
15 _next/favicon.ico
16 _next/index.html
17 _next/vercel.svg
A side note
  • in nextjs I have to get rid of import img before doing static export as otherwise it gives error
  • nextjs image optimisation is not available in statics export
  • in Hugo I can use webp q80 for basic optimisation in static export.
  • by applying a simple disableKinds = ["taxonomy", "taxonomyTerm", "category", "sitemap"] I can reduce the exported files to only 1 in Hugo (I think I can also get rid of index.xml but I haven’t tried this feature yet)

So since I am Hugo beginner instead of doing things the traditional way I will give the Hugo way of things try to see the full benefit of it. The only thing I struggle with is Hugo module comparison to the traditional method. if there was a page with Hugo module vs bla bla that will paint the full picture for beginners like me.

Thanks for taking the time

1 Like

After almost two months of utilizing Hugo modules, there is only one thing I dislike about it: when I launch hugo or hugo server, existing modules are auto-downloaded. The automated downloading then displays JS faults, but those errors disappear after running hugo mod clean.

When compared to Npm packages, it appears that the user has little control over Hugo modules. With Npm developer decides on when to update packages, doesn’t seems to be the case with Hugo modules.

I hope it will be useful to anyone who is learning Hugo in the same way that I was two months ago.

Thanks

1 Like

I would argue it’s the other way, but eye is in the beholder.

A post was split to a new topic: Problem with Hugo modules