tilde sass import from node_modules library

[dagda1]

Describe the bug

I have a sass file that includes an @import to a file in a package in node_modules

@import '~@cutting/component-library/src/styles/_index.scss';

I get this error:

Can't find stylesheet to import.

@import '~@cutting/component-library/src/styles/_index.scss';
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This is getting raised from this line in cssSnapshots.js

            transformedCss_1 = sass
                .renderSync({
                data: css,
                includePaths: [filePath],
            })
                .css.toString();

To Reproduce
Steps to reproduce the behavior:

1. add an import to a package in node_modules

Expected behavior
The sass file should be properly parsed and the declarations created

Desktop (please complete the following information):

• OS: OSX

Perhaps the node_modules folder should be added to includePaths in the call to sass.renderSync

[mrmckeb]

Hi @dagda1, you might be right on the suggested solution, this is definitely something we can add in.

Unfortunately these things are hard, as we can't know a user's configuration for Sass/Wepback/etc, so everything we're doing here is best effort.

If you want to take a swing at this, let me know - if not, that's fine. I'm on a business trip in London and time is short for the next 2-3 weeks... but I can find time this weekend for sure.

[dagda1]

@mrmckeb This might be trickier than I first thought. The tilde thing is what sass-loader uses, so I'm exploring how they handle it.

already looking into it :), do you have any other tips for debugging apart from lots of logger.info statements?

[dagda1]

@mrmckeb I've been doing some detective work and the ~ was actually a workaround in the sass-loader that was fixed in this PR.

If I remove this tilde from my import and include node_modules in the includePaths in renderSync then all is good.

      transformedCss = sass
        .renderSync({
          data: css,
          includePaths: [
            filePath,
            'node_modules'
          ],
        })
        .css.toString();

The above would fix my problem if I was in a single repo and not a monorepo.

I have this setup for my bug:

monorepo
 |_node_modules
   |_typescript-plugin
 |_packages
   |_website
     |_node_modules
       |_package_a
         |_index.scss

If I open visual studio at website then node_modules would resolve to `path.join(process.cwd(), 'node_modules').

But if I open at the root of monorepo which I normally do then sass looks in monorepo/node_modules/ and not packages/website/node_modules.

I can fix this by manually adding website to the includedPaths like this:

includePaths: [filePath, 'node_modules', path.join(process.cwd(), 'packages', 'website', 'node_modules')], which obviously is not a real fix.

I can't think of an elegant fix for this unless we could allow the users to pass in a string array of paths to include in the options:

export interface Options {
    camelCase?: CamelCaseOptions;
    customMatcher?: string;
    includedPaths?: string[];
}

I think at the very least, the node_modules string literal should be added to the call to renderSync call:

                sass
                    .renderSync({
                    data: css,
                    includePaths: [filePath, 'node_modules',
                })
                    .css.toString();

But allowing the user to supply includedPaths might get around a lot of problems in the same way as webpack allows you to supply modules:

    resolve: {
      modules: ['node_modules', paths.appNodeModules].concat(
        modules.additionalModulePaths || []
      ),

Create-react-app does some shenanigans here I might checkout here.

[mrmckeb]

Again, sorry for the slow reply... I'm in London working still, I'll not be back home for two more weeks, but I'm trying to find time where possible.

I agree with you, I think adding an option for this makes sense. We could just call it paths as in tsconfig.json.

I'm on the Create React App team, we've moved to using TypeScript's settings (from tsconfig.json or jsconfig.json) where possible, but again I think your suggestion is a good fix for now.

I can add this in before release of 1.3.0, as it'll be a quick one.

[amelekhin]

But allowing the user to supply includedPaths might get around a lot of problems in the same way as webpack allows you to supply modules

This should work fine for imports that are located in node_modules or linked through resolve.modules, but I doubt it would work for resolve.alias as well. It feels like includedPaths should utilize the compilerOptions.paths option's format. I wonder, is there a way to make use of compilerOptions.paths values directly in the plugin?

[mrmckeb]

Yes, that's a good idea @amelekhin - and sorry for the delay, I've been away for two weeks.

Would you like to take a look at that?

[mrmckeb]

Hi @dagda1, we've just released v2.0.0 which should solve this issue by allowing users to pass through options to Less and Sass.

Release notes and migration steps can be found here: https://github.com/mrmckeb/typescript-plugin-css-modules/releases/tag/v2.0.0

Please let me know if you have any other issues or feedback! And thanks for your patience.