Question: Does this plugin work with the .mjs extension?

[amilajack]

This plugin doesn't seem to work with the .mjs extension. I'd like to confirm if this is true or not so I know if I just misconfigured it

[mzgoddard]

This plugin should work with the .mjs extension. I don't recall having a test for it yet in hard-source but there are a lot of webpack plugins, loaders, features that work with hard-source-webpack-plugin without needing explicit support.

[phaistonian]

Confirming it.

Does not seem to work. Try importing from this package.

Also, on a rather related note, when importing .json files and then you reload, all sorts of .replace-related errors come up. Converting the files from json ones to .js ones (export defult JSON_OBJECT), does the trick.

[mzgoddard]

@phaistonian can you make a reproduction repo that works without hard-source and breaks when hard-source is added to plugins?

webpack treats mjs special as an extension for configuration but in mechanisms like module dependencies it uses the same data model for javascript modules as for other extensions. You may be experiencing that special default configuration.

Have you tried the latest or next versions of hard-source? json files to my knowledge were fixed a few weeks ago in hard-source.

[phaistonian]

@mzgoddard I will try and find some time and do so, however, a minimal project using idb keyval will do it, since the module key to its package.json points to a .mjs file －as seen here.

My first thought was to try what Tobias suggested, but it did not work either.

I am using hard-source-webpack-plugin@0.7.0-alpha.2.

[mzgoddard]

@phaistonian Thanks for the reply. I put together an example project with hardsource, webpack, and idb-keyval. https://github.com/mzgoddard/hardsource-webpack-idbkeyval-mjs In this example mjs files work with or without hardsource. Disabling the explicit config for mjs will stop the module version of keyval loading but only for module.mjs (a file in the example). The common js file will still load the module version. This is the expected node-like behaviour.

Let me know if you find anything to be different on your system or if you figure anything else out on this.

[phaistonian]

Well, one theory is that perhaps since I am using both happypack, cache-loader and hard-source-webpack-plugin something gets messed up somewhere along the process.

The following error － which I am getting way too often lately － points to that, or so I think.

btw, the only way to resolve this is to reinstall the plugin, i.e yarn add hard-source-webpack-plugin@next.

I shall investigate further and get back to you.

Thank you.

---

It seees that @next caused this. Using @latest seems to do work fine －so far.

[mzgoddard]

happypack and hardsource are known to work together well. They own different sets of work. happypack works with the module build process and hardsource freezes the build output. Frozen modules may rebuild if their dependencies changed the same way it would happen without hardsource.

There may be a loader used in the happypack config that does not work with hardsource. I don't think it'd be cache-loader. Let me know if you find more on this front.

---

Regular new config hashes sound to me like a changing webpack config. The change is probably a value on a plugin that changes each build and somehow stabilizes when yarn is run. That's pretty odd.

---

It seees that @next caused this. Using @latest seems to do work fine －so far.

That's pretty surprising to me. Hmm.

[phaistonian]

Since downgrading to latest, this error has indeed gone.

I would happily send you my 324 lines webpack.config file to take a look, if you want to.

ps: This is about a rather big project: > 3.5k modules.

[mzgoddard]

Since downgrading to latest, this error has indeed gone.

Has anything else changed? I'm trying to hunt down what may be causing extra config hash renewals. I can't find or recall what would affect the config hash in the 0.7 series.

What order is HardSource in the plugins list? First? Last? One thought is a plugin may modify the configuration before HardSource sees it making it a little random. Setting HardSource first would avoid this.

[phaistonian]

Yes, it's the last one.

I will push it to be first, though.

Here's the block:

  config.plugins.push(new HardSourceWebpackPlugin({
    cacheDirectory: '/tmp/.cache/hard-source-plugin/[confighash]',
    environmentHash: {
      root: process.cwd(),
      directories: [],
      files: ['package-lock.json', 'yarn.lock'],
    },
  }));

I will also remove the options and go with default, i.e no options.

If, after upgrading to 0.7x, the issue will remain, I will keep you posted here.

[phaistonian]

Update.

Tough luck, even by pushing it to the top I get.

Will be reverting to @latest for now :)