Upgrading to [email protected] generates properties from a source map

[atomrevival]

After upgrading to [email protected], it seems that I'm generating properties in my *.d.ts files from my *.scss file AND a source map file. The latter is an assumption due to what comes up in the list, { file, mappings, names, sources, sourcesContent, version, ...cssClasses }.

config

{
    test: /\.scss$/,
    use: [
        'style-loader',
        {
            loader: '@teamsupercell/typings-for-css-modules-loader',
            options: {
                banner:
                    '// generated by packages/components/.storybook/main.js\n\n',
            },
        },
        {
            loader: 'css-loader',
            options: {
                modules: {
                    auto: true,
                    exportLocalsConvention: 'camelCaseOnly',
                    localIdentName: '[name]__[local]--[hash:base64:5]',
                },
            },
        },
        {
            loader: 'postcss-loader',
            options: {
                ident: 'postcss',
                plugins: () => [postcssPresetEnv()],
            },
        },
        'sass-loader',
    ],
}

Expected behaviour:
Only CSS classes from a .scss file should be generated as types.

[Obi-Dann]

Thanks @atomrevival I'll have a look at this issue shortly

[shimizacken]

Seems that the cause of the issue is content.indexOf("exports.locals") that always returns -1. Changing it into indexOf(___.locals) fixing the issue and avoiding getting keys from the sourcemap.

const cssModuleKeys = getCssModuleKeys(
    content.substring(content.indexOf("exports.locals"))
  )

That's happen because since [email protected] is no longer exports locals with exports.locals string, but with ___CSS_LOADER_EXPORT___.locals.

Sources:

typings-for-css-modules-loader/src/index.js

Line 61 in 7a2b2e1

const cssModuleKeys = getCssModuleKeys(

[email protected]
https://github.com/webpack-contrib/css-loader/blob/d94a698d9d144fb91a9d1fdfb8cd4433e410e70e/src/index.js#L254

[email protected]
https://github.com/webpack-contrib/css-loader/blob/33e7879e1ebaffaa218d61cd307d9629e748abd4/src/utils.js#L524

@Obi-Dann I have a fix with tests, let me know if I can open PR 🙂

[Obi-Dann]

Thanks for the investigation @shimizacken!

I've a PR ready fixing the problem so it should be working with both css-loader 3 and 4. However, I'd have gladly accepted your PR, you don't need a permission to create a PR so please don't hesitate creating a PR next time. 😉

I am also going to setup a daily build with using both current dependencies from package-lock and latests so hopefully there'll be failing build if the loader stops working with the latest version of css-loader.

[shimizacken]

Thanks for the investigation @shimizacken!

My pleasure ☺️

I've a PR ready fixing the problem so it should be working with both css-loader 3 and 4. However, I'd have gladly accepted your PR, you don't need a permission to create a PR so please don't hesitate creating a PR next time. 😉

Thank you!

I am also going to setup a daily build with using both current dependencies from package-lock and latests so hopefully there'll be failing build if the loader stops working with the latest version of css-loader.

Sound like good approach 👌

I just tested the latest version and happy to confirm that it is fixed 👍

[atomrevival]

Awesome, you guys! Thank you! 👍