Reference `webpack.DefinePlugin` in the readme

[fregante]

webpack.DefinePlugin offer a native way to run simple replacements, which covers the first example.

I can open a PR that adds a link to this issue as documentation in the readme, and add more examples, including dynamic ones like refined-github/refined-github@130c110

With this loader

module.exports = {
  module: {
    rules: [
      {
        test: /fileInWhichJQueryIsUndefined\.js$/,
        loader: 'string-replace-loader',
        options: {
          search: '$',
          replace: 'window.jQuery',
        }
      }
    ]
  }
}

With DefinePlugin

module.exports = {
  plugins: [
    new webpack.DefinePlugin({
      $: 'window.jQuery'
    })
  ]
}

[pietia]

@fregante Isn't that DefinePlugin can operate only on entry points while string-replace-loader can update any file ?

[fregante]

DefinePlugin will operate on any file in the dependency graph. I think that’s the same for this loader, I don’t think it will actually pick files directly from the file system

[pietia]

@fregante i would have to double check it but i didn't have luck to make DefinePlugin (search / replace functionality ) work with any other file than entry point.

[fregante]

In Refined GitHub we replace a variable in sub-dependencies of the entry point:

https://github.com/sindresorhus/refined-github/blob/f8c2fab4cfd8f85f19552a897f1a6df49ea441d9/webpack.config.ts#L108-L110

• content.ts is the entry point
• the variable is in a file imported by content.ts: https://github.com/sindresorhus/refined-github/blob/f8c2fab4cfd8f85f19552a897f1a6df49ea441d9/source/features/copy-on-y.tsx#L21

[pietia]

Thanks. Unfortunately, our project architecture is much more complicated and the file we would like to update with DefinePlugin is not referenced from entry point .

[fregante]

our project architecture is much more complicated

Right. As I said in my first paragraph:

webpack.DefinePlugin offer a native way to run simple replacements

What you want to do probably isn't covered by that plugin — which, by the way, works on any JS file; its import position doesn't matter as long as you use it as it's supposed to be used.

[pietia]

I've refactored my project so that i can use DefinePlugin , so - case closed.

[Va1]

hi folks. the mentioned webpack.DefinePlugin is, first of all, a plugin, while this codebase is a loader. their use-cases seem to overlap, but are not equal. i am not sure of why it should be referenced here in this readme, if it is extensively documented in webpack docs and is, apparently, a standard way of performing replacements and some other things. why?

[fregante]

Because why use a 3rd party loader when you can do it "natively" and with less config?

string-replace-loader is useful for full string replacements, but 2 examples in the readme are a plain variable replacement that Webpack supports.

If the intent of this module is to help the user, let's direct them to better solutions.

[Va1]

as i mentioned in the previous comment, string-replace-loader is a loader on contrast to DefinePlugin being a plugin. this means, that it can be used for specific files via regex (as loaders are defined with test property) and, what's more important, in specific positions in the loader chain (before loader A does it's job, but over results loader B has produced, if defined between em).

this, i believe, makes both just different tools, use-cases of which intersect but are not equal by any means. which invalidates the "why 3rd party loader" question, in my opinion. examples defined in readme are plain variable replacement ones, but this does not deny the point i wrote above, as well as does not mean that more complex examples should be added to justify its existence (or does it? and does this module lack examples overall?).

what may be a justified thing to do is to reference the DefinePlugin in a form like "yo btw, if what you're doing is a simple & global variable replacement, you may be able to achieve it via DefinePlugin, read more here". but the emphasis on examples seems a bit over the top to me (i might be wrong tho).