files option doesn't work as expected?

[tuananh]

i have this manifest.json like this

<link rel="manifest" href="/assets/manifest.json">

after enable cdnizer, i got

<link rel="manifest" href="//mycdn.com/assets/manifest.json">

even though i already set files in cdnizer options to be like below: only css/js and images

{
              defaultCDNBase: '//mycdn.com',
              files: ['**/*.{css,js,svg,gif,png,jpg,jpeg}']
            },

[OverZealous]

I'm assuming it's matching because **/*.js effectively expands to something like /.*\.js/, which is matching anything that has .js in it.

This is related to using globbing for the matches.

The best bet here is to be more specific in your matcher(s), and include some path information. You'll not only will avoid this issue (and other unexpected issues), the matchers won't have to work as hard.

I generally don't recommend generic globbing.

[tuananh]

@OverZealous i change it to be files: ['**/*{chunk,bundle}*.{css,js}'] which should not match manifest.json but it's still change. Any idea?

[OverZealous]

Sorry, when I run it through globtester.com, it works as expected.

Interestingly, I'm not seeing the matcher fail with your original generic matcher, either.

Try making a minimal test case (the smallest possible scenario in which you can see this happening) to remove any external influence on the output.

I honestly don't use this library, and haven't actively worked on it in a long time. I know a lot of people do, though, so it definitely works as expected in many cases.

[OverZealous]

It's also possible the cdnizer is modifying the glob in some unexpected manner.

If you look inside lib/parseOptions.js, you can see how it manipulates the glob. It's possible you will want to disable allowRev and allowMin (if they aren't already disabled).

[tuananh]

@OverZealous seems to be issue with the plugin that make use of cdnizer. Thank you for your support.