Filtering relative path would fail to transform hoisted dependencies in monorepos.

[nandin-borjigin]

Consider a project structure like this:

my-project/
- node_modules/
  - some-awesome-style-lib/
    - dist
      - awesome.css
- packages/
  - pkg1/
    - main.js // import 'some-awesome-style-lib/dist/awesome.css'
    - rollup.config.js // uses rollup-plugin-scss

some-awesome-style-lib is under root node_modules because

• yarn workspace
• Or hoisted by lerna --hoist
• Or other fancy reasons

When rolling this kinda configuration, rollup would ask each plugin to transfrom /path/to/my-project/node_modules/some-awesome-style-lib/

And the rollup-plugin-scss uses the following code to filter the id https://github.com/thgh/rollup-plugin-scss/blob/4456aa72dc780435874b72a6ab5fc7943e65404c/index.es.js#L6

createFilter does this under the hood:

micromatch.matcher(path.resolve('**/*.css'))

// which is 

micromatch.matcher('/path/to/my-project/packages/pkg1/**/*.css')

thus awesome.css is refused by rollup-plugin-scss and that causes rollup to throw Unexpected token

I did a small experiment (by modifying the code directly in node_modules) to change **/*.css to /**/*.css and it worked as expected.

I'm wondering can we just change the filters (['**/*.css', '**/*.sass', '**/*.scss']) to absolute ones (['/**/*.css', '/**/*.sass', '/**/*.scss']) ? Would doing so has any potential defects ?

[thgh]

Sounds good, is this common in Rollup plugins?