I was super excited with the features introduced in v0.78, but doesn’t seem to solve this use case: https://github.com/gohugoio/hugo/issues/7474#issuecomment-662424433
I still get the same error 
. f that’s supposed to work I can double-check everything in my side, but that min repro doesn’t seem to work…
Today’s release is not about node_modules, it’s about _everything else (I assume you want me to tone down the “full support” title, but I will not do that). So, for third-party “imports” in a theme component you have 2 options:
npm install all it needs. hugo mod npm pack can help here.There is an argument for Hugo to somehow do 1) Automatically, but I’m not ready for that, yet. Me, as a project owner, very much like to see what “cat dragged in” from NPM.
Thanks for the answer @bep!
Option 1 means that everything should work if the node_modules dependency (core-js in this case) is part of the package.json of the project that uses the theme, and that npm install is run, isn’t it?
I think that I’m already doing that…
Yes … But I will check this and come back. Looking at the test coverage I may have been a little too exited about the “other stuff” and just assumed this would work.
OK, you are right:
I will look into that tomorrow… Thanks for the report.
OK, I have a possible fix that I need to polish a little. I may ask for a cleaner solution upstream, but it should work for now.
If you have a link to a test project, please share and I will test it.
Mmm… I don’t. I tested it for a client and both the hugo site and the theme are private repos owned by the client. It might be easier if you upload the PR and I compile and test it… and if it doesn’t work I can prepare a min repro on top of GitHub - gohugoio/hugoBasicExample: Example site to use with Hugo & Hugo Themes . WDYT?
Thank you for looking at this and for all your work in the project. I’ve been using Hugo for 1.5 years, and is incredible how it has evolved with super useful features in this time 
.
I don’t need a test repo, just in case you had a link to some thing existing. I have reproduced it and I have a workaround. I will also create a test case to Evan Wallace in ESBuild to try to get a more sensible default behaviour, because this caught me by surprise (I expected it to just work).
OK!
BTW, the full use case I want to solve is the following one:
Have a theme module with some TS code, and inside the theme use js.Build (esbuild) to transpile it into ES2015 code. That would be the final bundle for modern browsers. But we also produce legacy bundles (compatible with IE11) taking that ES2015 code, running Babel to insert the necessary core-js dependencies, and js.Bulid/esbuild again to solve those dependencies and bundle everything.
This bug relates to that final step. Let’s hope everything else works as expected once that is ironed out 
.
Turned out ESBuild’s plugin API actually supported what we want, so I could remove my ugly workaround. I will release a patch release tomorrow – and also write some better docs in this area.
