Why is createFilter is scoped to process.cwd?

[tivac]

rollup-pluginutils/src/createFilter.js

Line 6 in 0b1887c

const getMatcher = id => ( isRegexp( id ) ? id : { test: mm.matcher( resolve( id ) ) } );

If you invoke createFilter() with a string for include or exclude it'll be run through path.resolve before it's passed to mm.matcher().

Why?

It means that unless you pass a regular expression matcher all globs will only match files underneath process.cwd(). This cropped up as I tried to move my fixtures to the system temp folder and suddenly my plugin's filters stopped matching anything because they're all scoped. It seems like it'd be more intuitive for the glob to be passed to mm.matcher() w/o the resolving.

const { createFilter } = require("rollup-pluginutils");

const filter = createFilter("**/*.css");

// Now filter() is matching against
`${process.cwd()}/**/*.css`

// instead of what I expected, which is
`**/*.css`

[guybedford]

I'd be open to changing this to something more sensible, but we need to be careful about backwards compat etc.

Would you be interested in working on a PR?

[tivac]

What would a sensible back-compat approach be? An options object as the third arg to createFilter() that could be { resolve : false } to disable the behavior?

For now I've worked around by using a RegExp instead of a glob. It's not a pressing concern, just something that really threw me for a bit when my tests were failing.

[Hexxeh]

This seems to have another unintended effect too, whereby the path of the current directory is considered as part of the match pattern. Therefore, if your current directory contains characters that have special meaning in regexp, you might not match the files you expected to.

[nandin-borjigin]

I have run into similar problem.
thgh/rollup-plugin-scss#22

This kinda situation may occur frequently in a monorepo since 3-rd party dependencies are tend to be hoisted to the root directory.

I understand that 3rd party files have better treated as externals and the problem would be resolved. But there still are circumstances where bundling certain dependencies is required (e.g. say rolling up the final output of the monorepo)

[sormy]

the workaround is to use minimatch patterns starting with / like "/**/*.css"

[tivac]

@sormy That workaround didn't work for me, it just mean that my plugin never matched any files.

For now I've been using /\.css$/i and that seems to be fine-ish. @guybedford or @lukastaegert I'd still be willing to do the work to get a PR up for this if you have a preferred approach so I don't flop around too much.

[lukastaegert]

I created #61 to address this (as I need this myself for package side-effects in rollup-plugin-node-resolve). I would still stick with the default as it currently provides a consistent experience across the rollup ecosystem. However if you have special needs, you can now configure it.

[hiendv]

For the record, #61 does not resolve the problem with monorepo setup where dependencies are hoisted. Use #39 (comment) instead.