jimdo / typings-for-css-modules-loader Goto Github PK

Good day,

When using the typings-for-css-modules-loader for CSS modules that have only :global styles, the module definitions is not generated if a file has only :global styles:

:global(.foo) {
  // ..
}

:global(.bar) {
  // ..
}

So we have to add an empty class name with empty styles on it:

// useless class name with "empty" styles
// to make the types module compilation work
.empty {
  opacity: 1; // default styles
}

:global(.foo) {
  // ..
}

:global(.bar) {
  // ..
}

Interesting to know your thoughts regarding this, do you consider this as a bug?
Thanks in advance.

CSS modules the exported module is an empty object?

https://stackoverflow.com/questions/53754359/css-modules-the-exported-module-is-an-empty-object

Using a complex docker setup, and I have my sources mounted as a read-only volume. The build fails with this error:

server_1    |         ERROR in ./node_modules/typings-for-css-modules-loader/lib?{"camelCase":true,"modules":true}!./node_modules/sass-loader/lib/loader.js!/site/src/pages/styles/common.scss
server_1    |         Module build failed: Error: EROFS: read-only file system, open '/site/src/pages/styles/common.scss.d.ts'
server_1    |           at Object.fs.openSync (fs.js:651:18)
server_1    |           at Object.fs.writeFileSync (fs.js:1300:33)
server_1    |           at writeFile (/dist/node_modules/typings-for-css-modules-loader/lib/persist.js:34:24)
server_1    |           at Object.writeToFileIfChanged (/dist/node_modules/typings-for-css-modules-loader/lib/persist.js:26:5)
server_1    |           at /dist/node_modules/typings-for-css-modules-loader/lib/index.js:92:15
server_1    |           at Object.<anonymous> (/dist/node_modules/css-loader/lib/localsLoader.js:44:3)
server_1    |           at /dist/node_modules/css-loader/lib/processCss.js:207:3
server_1    |           at <anonymous>:null:null

It would be great if there was a way to adjust the output directory for the definition files.

@timse
I want to create a PR for a feature we need to continue using this project.

Our issue is:
We are a react app that consumes a UI Library a bit heavily for control we need. But the controls don't match our styling. So we've added CSS overrides that specifically use their class name, ie:

.ourControl {
    .their-control-class-name {
        color: red;
    }
}

When we have hashing enabled ( localIdentName: "[name]_[local]_[hash:base64:5]",), we get the following:

Component_ourControl_12345
Component_their-control-class-name_23456

This isn't ideal because their-control-class-name is controled by them, not us.

So what we're thinking to solve this is add an option for the loader that accepts an array of "test" values (Not sure the proper name, but specifically something like webpack's /\.scss$/).

So we could do something like:

                        loader: "typings-for-css-modules-loader",
                        options: {
                            localIdentName: "[name]_[local]_[hash:base64:5]",
                            excludedClassNames: [
                                /their-control-class-name/,
                            ]
                        }

This would result in the following instead:
Component_ourControl_12345
their-control-class-name

We haven't started work on this yet as we wanted to know if this would be an acceptable PR.

Thanks!

As of version 1.7.0 and typescript 2.9.2 and contrary to the documentation, no default export is provided on the [styles].css.d.ts file

e.g. with a create-react-app new project

export interface IAppCss {
  'App': string;
  'logo': string;
  'logoSpin': string;
  'header': string;
  'title': string;
  'intro': string;
  'button': string;
}

export const locals: IAppCss;

this seems to cause some problems with importing the styles into the component with e.g.

import locals from './App.css

restoring the export default by changing

 return 'export interface ' + interfaceName + ' {\n' + interfaceProperties + '\n}\n\nexport const locals: ' + interfaceName + ';\n';

to

 return 'export interface ' + interfaceName + ' {\n' + interfaceProperties + '\n}\n\nexport const locals: ' + interfaceName + ';\n\nexport default locals;\n';

in typings-for-css-module-loader/lib/cssModuleToInterface.js line 79 restores what I imagine to be the desired behaviour.

Perhaps I am missing something?

We're very happy with this tool, but we're experiencing a weird behavior when checking out branches with different styles among them.

Since our autogenerated scss.d.ts files are included in .gitignore, they are kept locally when checking out to another branch. If styles are different among them, this leads to compilation issues (using yarn build, our gulp build script using webpack, etc)... Compilation can't be fixed unless we manually remove all autogenerated scss.d.ts files, because they're not being updated.

I'm sure we're doing something wrong, because I don't believe the rest of you are experiencing this issue. Are you git ignoring these files? Is it normal that scss.d.ts files are not being properly regenerated when this file already exists, even if the scss files are different?

Thank you very much for your time!

I am developing an isomorphic app and style-loader/useable and use such operator

import appStyles from './app.css';
...
const css = process.env.__BROWSER__ ? appStyles.locals : appStyles;
...
if (process.env.__BROWSER__ ) {
    appStyles.use();
}
...
<div className={css.btn} />

so I need to have both declarations and also to have declared use and ``unuse``` methods

What is needed:
app.css

.hello {
    color: red;
}

app.css.d.ts

export interface IAppCss {
    hello: string;
}
export const hello: string;

export const locals: IAppCss;
export const use: Function;
export const unuse: Function;

Propose to add an option flag isomorphic: boolean (false by default)

I am using a TypeScript-powered Webpack configuration file and in order to use path aliases defined in my tsconfig.json I rely on using tsconfig-paths. Unfortunately TypeScript configuration files for Webpack happen to behave rather erratic and the described method in the documentation does not work at all. Therefore I had to bootstrap my configuration file and add require("tsconfig-paths").register(); as the very first line in my configuration file which fixes issues regarding module resolution.

Unfortunately typings-for-css-modules-loader runs into issues with that bootstrap command enabled and yields the following error:

ERROR in ./Source/Styles.scss (./node_modules/typings-for-css-modules-loader/lib??ref--5-1!./node_modules/sass-loader/lib/loader.js!./Source/Styles.scss)
Module build failed (from ./node_modules/typings-for-css-modules-loader/lib/index.js):
TypeError: query.substr is not a function
    at Object.parseQuery (D:\Source\electron-typescript-boilerplate\node_modules\loader-utils\lib\parseQuery.js:12:11)
    at Object.module.exports (D:\Source\electron-typescript-boilerplate\node_modules\typings-for-css-modules-loader\lib\index.js:54:37)
 @ ./Source/Styles.scss 2:14-152 21:1-42:3 22:19-157
 @ ./Source/App.tsx
 @ ./Source/Index.tsx
 @ multi (webpack)-dev-server/client?http://localhost:3000 (webpack)/hot/dev-server.js webpack-dev-server/client?http://localhost:3000 webpack/hot/only-dev-server ./Source/Index.tsx

The loader configuration looks as follows:

{
    test: /\.scss$/,
    use: [
        { loader: "style-loader" },
        {
            loader: "typings-for-css-modules-loader",
            options: {
                modules: true,
                namedExport: true,
                camelCase: true,
                localIdentName: "[folder]-[local]-[hash:base64:8]",
                banner: [...constants.copyrightHeaderLines, ...constants.generatedHeaderLines].join("\n"),
            },
        },
        { loader: "sass-loader" },
    ],
}

Is there any way to help you figure out where this error comes from?

Would it be possible add a way to exclude the exported values from imported SCSS? For example, if button.scss imports colors.scss, currently every exported value in colors.scss is added to button.scss.d.ts, and to every other typings file that imports colors.scss. If you are exporting a lot of values from files that get included a lot, this can get pretty nuts. Would be nice to have an alternative behavior.

Hi!
I am trying to make webpack produce the scss typings, together with a main.css file in the output dir that holds the same classes as the generated scss module (I've inspected the main.js and there is css created there, but since I am not injecting it on an index file automatically I am clueless on how to use it).

So, using webpack --mode development produces the correct main.css file, but it breaks my JS. Using webpack --mode production produces functional JS code with proper typings next to each css file, but no main.css. So I am doing 2 passes, one in development and copying the main.css to a distribution folder, and another production pass and copying the main.js to that distribution folder as well.
This is very hacky to say the least. Also tried to check if there are ways to process each file type with multiple loaders but not chained, or if there were any pluings for pre compilation hooks to produce that main.css file, but haven't found anything that will let me develop with ease and reload upon changes on my stylings, so I am asking you guys for help with webpack 4 configurations for this loader module.

Code:

const prodSCSS = 'typings-for-css-modules-loader?modules&sass&banner=// This file is automatically generated by typings-for-css-modules.\n// Please do not change this file\n\n';
const devSCSS = ExtractTextPlugin.extract('typings-for-css-modules-loader?modules');
...
{
    test: /\.scss$/,
    include: path.join(__dirname, 'src'),
    loader: argv.mode === 'production' ? prodSCSS : devSCSS
}

Thanks in advance!

Is there a way to put the typing definitions in a different folder than the source CSS file is? I like this because it makes it easier to look through my css files.

why pr not merged

If I have the following sass class:

.new {
composes: test from "./test.scss";
}

and in ./test.scss:

.test {
color: red;
}
compiling gives me the following error, then node crashes:

(node:26366) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): TypeError: Cannot read property 'length' of undefined

Removing the composes fixes the issue, but it works with regular css-loader.

Would love to be able to utilize css module composition in conjunction with this.

Configuration:

{ test: /\.tsx?$/, loader: 'awesome-typescript-loader' },
{ enforce: 'pre', test: /\.js$/, loader: 'source-map-loader' },
{ test: /\.css$/, use: [ 'style-loader', 'typings-for-css-modules-loader?modules&namedExport&camelCase' ] }

Steps to reproduce:

1. Start webpack in watch dev server mode
2. Create new css file like test.css (or add new classifiers)
3. Include this file in typescript component import * as css from './test.css';

We can watch that test.css.d.ts was generated after we added import and ts loader see this as error.

ERROR in [at-loader] ./src/component.tsx:3:22 
TS2307: Cannot find module './test.css'

After re-running webpack error is gone.

TS-loader needs to wait till *.css.d.ts files are generated - somehow (not sure if it's possible), but it's essential to make this loader totally awesome :)

If there is some hotfix, or I am using configuration incorrectly please give me tips how to apply fix - Thanks.

$ npm run test:run

> [email protected] test:run /home/davidm/src/Jimdo/typings-for-css-modules-loader
> babel-node ./node_modules/webpack/bin/webpack --config ./test/webpack.config.babel.js && npm run test:diff

ts-loader: Using [email protected] and /home/davidm/src/Jimdo/typings-for-css-modules-loader/test/tsconfig.json
Hash: 743acee40bc0d406534c
Version: webpack 1.14.0
Time: 1626ms
    Asset     Size  Chunks             Chunk Names
bundle.js  3.08 kB       0  [emitted]  main
   [1] ./test/example.css 0 bytes [built] [failed]
   [2] ./test/example-camelcase.css 0 bytes [built] [failed]
   [3] ./test/example-namedexport.css 0 bytes [built] [failed]
   [4] ./test/example-camelcase-namedexport.css 0 bytes [built] [failed]
    + 1 hidden modules

ERROR in ./test/entry.ts
(1,36): error TS2307: Cannot find module './example.css'.

I am using this loader setup for TypeScript and PostCSS with Webpack 1.13.1:

{
  test: /\.tsx?$/,
  loader: 'ts',
  exclude: /node_modules/
},
{
  test: /\.css$/,
  loader: 'style!typings-for-css-modules?modules&camelCase!postcss',
  //loader: 'style!css!postcss'
}

(The commented out css loader is the previous setup which works without CSS modules.)

When I import a .css file using import {locals as styles} from "./example.css" as the generated typings indicate, I get nothing at runtime. If I use import * as styles from "./example.css" I see all the class names at runtime, but still no locals, and TypeScript flags errors for all references, such as styles.myClassName.

I was looking at the code in persist.js and had a couple observations.

export const writeToFileIfChanged = (filename, content) => {
  try {
    const currentInput = fs.readFileSync(filename, 'utf-8');
    const oldHash = crypto.createHash('md5').update(currentInput).digest('hex');
    const newHash = crypto.createHash('md5').update(content).digest('hex');
    // the definitions haven't changed - ignore this
    if (oldHash === newHash) {
      return false;
    }
  } finally {
    fs.writeFileSync(filename, content);
  }
};

Comments...

• Because the fs.writeFileSync is in the finally, it will write the file regardless of whether the return false statement is reached or not. If this was done on purpose, what was the reason?

• Because we have the full content of both files, there's not really a reason to compare hashes. It would be faster to compare them directly b/c it can short circuit, whereas the hash always has to process the full contents. I doubt this matters in the grand scheme of things, but it would simplify a bit.

when i start webpack-dev-server i get 12 webpack rebuilds (last 6 catched by browser)

my build steps:

1. webpack-dev-server starts initial build
2. loader generates d.ts file
3. webpack see change in d.ts and queue new build
4. browser starts loading
5. webpack start rebuilding -> step 2
6. after some time browser wds is initialized and starts refreshing modules (in my case around 6 build)
7. webpack gives up after 12 builds (guessing there is some sort of check for infinite build loop)
8. when i change some styles in css (no class change) -> webpack rebuild once
9. when i add new class in css -> webpack rebuild twice

start command:

webpack-dev-server --hot --history-api-fallback --config webpack.config.dev.js

configuration:

{   
    module: {
        rules: [
            { test: /\.tsx?$/, exclude: /node_modules/, use: ['babel-loader', 'awesome-typescript-loader'] },
            { test: /\.css$/, exclude: /node_modules/, enforce: 'pre', use: ['style-loader', { loader: 'typings-for-css-modules-loader', options: { modules: true, namedExport: true } }] }
        ]
    },
    devtool: 'source-map',
    plugins: [
        new webpack.IgnorePlugin(/\.d\.ts$/),
        new webpack.NamedModulesPlugin()
    ],
    devServer: {
        port: 9000
    }
};

standart usage:

import * as css from './style.css';

<div className={css.class}></div>

any idea how to remove additional builds when d.ts changes?

I want to leave a quick note about how this can be used with the extract plugin very easily.
This works fine for me:

    {
      test: /\.scss$/,
      loader: ExtractTextPlugin.extract('typings-for-css-modules?modules&sass&namedExport'),
    },
    {
      test: /\.css$/,
      loader: ExtractTextPlugin.extract('typings-for-css-modules?modules&namedExport'),
    },

//package.json 
  "dependencies": {
    "@types/react": "^16.3.14",
    "@types/react-dom": "^16.0.5",
    "antd": "^3.5.2",
    "babel-preset-stage-2": "^6.24.1",
    "mobx": "^4.2.1",
    "mobx-react": "^5.1.2",
    "react": "^16.3.2",
    "react-dom": "^16.3.2",
    "react-router-dom": "^4.2.2"
  },
  "devDependencies": {
    "awesome-typescript-loader": "^5.0.0",
    "babel-core": "^6.26.3",
    "babel-loader": "^7.1.4",
    "babel-plugin-transform-decorators-legacy": "^1.3.4",
    "babel-preset-env": "^1.6.1",
    "babel-preset-react": "^6.24.1",
    "css-loader": "^0.28.11",
    "html-webpack-plugin": "^3.2.0",
    "less": "^3.0.4",
    "less-loader": "^4.1.0",
    "source-map-loader": "^0.2.3",
    "style-loader": "^0.21.0",
    "ts-import-plugin": "^1.4.4",
    "typescript": "^2.8.3",
    "typings-for-css-modules-loader": "^1.7.0",
    "url-loader": "^1.0.1",
    "webpack": "^4.8.1",
    "webpack-cli": "^2.1.3",
    "webpack-dev-server": "^3.1.4"
  }

//webpack.config.js
// webpack.config.js
const path = require('path');
const HtmlWebpackPlugin = require('html-webpack-plugin');
const tsImportPluginFactory = require('ts-import-plugin')
const webpack = require('webpack');

module.exports = {
    entry: {
        index:'./src/index.js',
    },
    output: {
        filename: 'bundle.js',
        path: path.resolve(__dirname, 'dist')
    },
    devtool: "source-map",
    resolve: {
        extensions: ['.ts', '.tsx', '.js', '.jsx', '.less', '.css']
    },
    // mode:'development',
    module: {
        rules: [
            {
                test: /\.css$/,
                use: ['style-loader', 'css-loader']
            },
            {
                test: /\.less/,
                use: [
                    'style-loader',
                    'typings-for-css-modules-loader?modules&importLoaders=1&localIdentName=[name]__[local]___[hash:base64:5]&namedExport&camelCase&less!less-loader'
                ]
            },
            {
                test: /\.(png|svg|jpg|gif)$/,
                use: ['url-loader']
            },
            {
                test: /\.(woff|woff2|eot|ttf|otf)$/,
                use: ['url-loader']
            },
            {
                test: /\.(js|jsx)$/,
                exclude: /node_modules/,
                use: {
                    loader: 'babel-loader'
                }
            },
            // All files with a '.ts' or '.tsx' extension will be handled by 'awesome-typescript-loader'.
            {
                test: /\.tsx?$/,
                loader: "awesome-typescript-loader",
                options: {
                    getCustomTransformers: () => ({
                        before: [ tsImportPluginFactory({
                            libraryName: 'antd',
                            libraryDirectory: 'es',
                            style: true,
                        }) ]
                    }),
                },
                exclude: /node_modules/
            },
        ]
    },
    plugins: [
        new HtmlWebpackPlugin({
            title: 'production',
            template: './index.html'
        }),
        new webpack.NamedModulesPlugin(),
        new webpack.HotModuleReplacementPlugin(),
        new webpack.WatchIgnorePlugin([
            /(less|css)\.d\.ts$/
        ])
    ],
    devServer: {
        contentBase: './dist',
        hot: true
    },
};

//tsconfig.json
{
  "compilerOptions": {
    "outDir": "./dist/",
    "sourceMap": true,
    "noImplicitAny": true,
    "module": "commonjs",
    "target": "es2017",
    "jsx": "react",
    "removeComments": true,
    "experimentalDecorators": true,
    "allowJs": true
  },
  "include": [
    "./src/**/*"
  ]
}

error demo

I am currently working with scss, typescript and react thing.
When is comes to element query thing I found this EQCSS is powerful to have a responsive element.
But I like this typings-for-css-modules-loader too to have a good control on the styles variables.
Can someone have a look?

I'm trying to integrate typings-for-css-modules-loader into a webpack 4 build together with sass-loader. I noticed that my build works with css-loader but of course no typings get generated.

How ever when I replace css-loader with typings-for-css-modules-loader typings get generated but I end up with errors down the line in style-loader that my sass files are invalid. (see below)

Here are my storybook 4 webpack configs:

working webpack config:

const pluginConf = [
  {
    loader: MiniCssExtractPlugin.loader,
  },
  {
    loader: 'css-loader',
    options: {
      sourceMap: true,
      root: path.resolve(__dirname, '..', 'src'),
    }
  },
  {
    loader: 'postcss-loader',
    options: {
      ident: 'postcss',
      plugins: () => [
        autoprefixer({
          'browsers': ['last 2 versions', 'ie >= 10'],
        }),
      ],
      sourceMap: true,
    },
  },
  {
    loader: 'resolve-url-loader'
  },
  {
      loader: "sass-loader",
      options:
      {
          sourceMap: true,
          modules: true,
          importLoaders: 1,
          localIdentName: '[name]__[local]___[hash:base64:20]'
      }
  }
];

// .....

defaultConfig.module.rules.push({
    test: /\.(sa|sc|c)ss$/,
    use: pluginConf,
    include: path.resolve(__dirname, "../src/app"),
    exclude: [
      path.resolve(__dirname, "../node_modules")
	]
});

none working webpack config:

const pluginConf = [
  {
    loader: MiniCssExtractPlugin.loader,
  },
  {
    loader: 'typings-for-css-modules-loader',
    options:
    {
        importLoaders: 1,
        modules: true,
        namedExport: true,
        camelCase: true,
        sourceMap: true,
        localIdentName: '[name]_[local][hash:base64:5]',
        banner: "// *** Generated File - Do not Edit ***"
    }
  },
  {
    loader: 'postcss-loader',
    options: {
      ident: 'postcss',
      plugins: () => [
        autoprefixer({
          'browsers': ['last 2 versions', 'ie >= 10'],
        }),
      ],
      sourceMap: true,
    },
  },
  {
    loader: 'resolve-url-loader'
  },
  {
      loader: "sass-loader",
      options:
      {
          sourceMap: true,
          modules: true,
          importLoaders: 1,
          localIdentName: '[name]__[local]___[hash:base64:20]'
      }
  }
];

// .....

defaultConfig.module.rules.push({
    test: /\.(sa|sc|c)ss$/,
    use: pluginConf,
    include: path.resolve(__dirname, "../src/app"),
    exclude: [
      path.resolve(__dirname, "../node_modules")
     ]
});

**Stacktrace: (and many more) **

ERROR in ./src/app/components/Base/Headline/styles.sass (./node_modules/css-loader??ref--10-1!./node_modules/postcss-loader/src??postcss!./node_modules/sass-loader/lib/loader.js!./node_modules/mini-css-extract-plugin/dist/loader.js!./node_modules/typings-for-css-modules-loader/lib??ref--12-1!./node_modules/postcss-loader/src??postcss!./node_modules/resolve-url-loader!./node_modules/sass-loader/lib/loader.js??ref--12-4!./src/app/components/Base/Headline/styles.sass)
Module build failed (from ./node_modules/sass-loader/lib/loader.js):

  text-transform: uppercase
              ^
      Invalid CSS after "module.exports": expected selector, was '= {"headline":"styl'
      in /path/to/project/src/app/components/Base/Headline/styles.sass (line 2, column 16)
 @ ./src/app/components/Base/Headline/styles.sass 2:14-554 21:1-42:3 22:19-559
 @ ./src/app/components/Base/Headline/index.tsx
 @ ./src/app/components/Base/index.ts
 @ ./src/app/stories/Base/Headline.stories.tsx
 @ ./src/app/stories sync \.stories\.(js|tsx|ts|jsx)$
 @ ./.storybook/config.js
 @ multi ./node_modules/@storybook/core/dist/server/config/polyfills.js ./node_modules/@storybook/core/dist/server/config/globals.js ./.storybook/config.js ./node_modules/webpack-hot-middleware/client.js?reload=true

I noticed that starting with css-loader 1.x are some breaking changes.
for example:

• remove minimize option, use postcss-loader with cssnano or use optimize-cssnano-plugin plugin
• remove module option, use modules option instead
• remove camelcase option, use camelCase option instead
• remove root option, use postcss-loader with postcss-url plugin
• remove alias option, use resolve.alias feature or use postcss-loader with postcss-url plugin
• update postcss to 6 version
• minimum require nodejs version is 6.9
• minimum require webpack version is 4

package.json

{
  "name": "the-project-name",
  "version": "1.0.0",
  "private": true,
  "dependencies": {
    "@material-ui/core": "^3.4.0",
    "@material-ui/icons": "^3.0.1",
    "async": "^2.6.1",
    "axios": "^0.18.0",
    "babel-polyfill": "^6.26.0",
    "chroma-js": "^1.4.0",
    "classnames": "^2.2.6",
    "core-js": "^2.5.7",
    "formik": "^1.2.0",
    "global": "^4.3.2",
    "immutable": "^3.8.2",
    "lodash": "^4.17.11",
    "material-design-icons": "^3.0.1",
    "mobx": "^5.6.0",
    "mobx-react": "^5.3.6",
    "mobx-state-tree": "^3.7.1",
    "raf": "^3.4.1",
    "react": "^16.6.1",
    "react-dom": "^16.6.1",
    "react-resize-detector": "^3.2.0",
    "react-router": "^4.3.1",
    "react-router-dom": "^4.3.1",
    "react-select": "^2.1.1",
    "spinkit": "^1.2.5",
    "yup": "^0.26.6"
  },
  "devDependencies": {
    "@babel/core": "7.1.0",
    "@svgr/webpack": "2.4.1",
    "@types/jest": "23.3.9",
    "@types/node": "10.12.5",
    "@types/react": "16.7.3",
    "@types/react-dom": "16.0.9",
    "babel-core": "7.0.0-bridge.0",
    "babel-eslint": "9.0.0",
    "babel-jest": "23.6.0",
    "babel-loader": "8.0.4",
    "babel-plugin-named-asset-import": "^0.2.3",
    "babel-preset-react-app": "^6.1.0",
    "bfj": "6.1.1",
    "case-sensitive-paths-webpack-plugin": "2.1.2",
    "chalk": "2.4.1",
    "css-loader": "1.0.0",
    "dotenv": "6.0.0",
    "dotenv-expand": "4.2.0",
    "eslint": "5.6.0",
    "eslint-config-react-app": "^3.0.5",
    "eslint-loader": "2.1.1",
    "eslint-plugin-flowtype": "2.50.1",
    "eslint-plugin-import": "2.14.0",
    "eslint-plugin-jsx-a11y": "6.1.2",
    "eslint-plugin-react": "7.11.1",
    "file-loader": "2.0.0",
    "fork-ts-checker-webpack-plugin-alt": "0.4.14",
    "fs-extra": "7.0.0",
    "html-webpack-plugin": "4.0.0-alpha.2",
    "identity-obj-proxy": "3.0.0",
    "jest": "23.6.0",
    "jest-pnp-resolver": "1.0.1",
    "jest-resolve": "23.6.0",
    "mini-css-extract-plugin": "0.4.3",
    "optimize-css-assets-webpack-plugin": "5.0.1",
    "pnp-webpack-plugin": "1.1.0",
    "postcss-flexbugs-fixes": "4.1.0",
    "postcss-loader": "3.0.0",
    "postcss-preset-env": "6.0.6",
    "postcss-safe-parser": "4.0.1",
    "react": "^16.6.1",
    "react-app-polyfill": "^0.1.3",
    "react-dev-utils": "^6.1.1",
    "react-dom": "^16.6.1",
    "resolve": "1.8.1",
    "sass-loader": "7.1.0",
    "style-loader": "0.23.0",
    "terser-webpack-plugin": "1.1.0",
    "typescript": "3.1.6",
    "url-loader": "1.1.1",
    "webpack": "4.19.1",
    "webpack-dev-server": "3.1.9",
    "webpack-manifest-plugin": "2.0.4",
    "workbox-webpack-plugin": "3.6.3",
    "@babel/polyfill": "^7.0.0",
    "@storybook/addon-a11y": "^4.0.4",
    "@storybook/addon-actions": "^4.0.4",
    "@storybook/addon-backgrounds": "^4.0.4",
    "@storybook/addon-centered": "^4.0.4",
    "@storybook/addon-events": "^4.0.4",
    "@storybook/addon-info": "^4.0.4",
    "@storybook/addon-jest": "^4.0.4",
    "@storybook/addon-knobs": "^4.0.4",
    "@storybook/addon-links": "^4.0.4",
    "@storybook/addon-notes": "^4.0.4",
    "@storybook/addon-options": "^4.0.4",
    "@storybook/addon-storyshots": "^4.0.4",
    "@storybook/addon-viewport": "^4.0.4",
    "@storybook/addons": "^4.0.4",
    "@storybook/client-logger": "^4.0.4",
    "@storybook/react": "^4.0.4",
    "@types/async": "^2.0.50",
    "@types/classnames": "^2.2.6",
    "@types/enzyme": "^3.1.15",
    "@types/lodash": "^4.14.118",
    "@types/react-resize-detector": "^3.1.0",
    "@types/react-router": "^4.4.1",
    "@types/react-router-dom": "^4.3.1",
    "@types/react-select": "^2.0.6",
    "@types/react-swipeable": "^4.2.1",
    "@types/react-test-renderer": "^16.0.3",
    "@types/storybook__react": "^4.0.0",
    "@types/yup": "^0.26.1",
    "autoprefixer": "^9.3.1",
    "awesome-typescript-loader": "^5.2.1",
    "axios-mock-adapter": "^1.15.0",
    "babel-plugin-transform-class-properties": "^6.24.1",
    "babel-plugin-transform-decorators-legacy": "^1.3.5",
    "babel-plugin-transform-es2015-modules-commonjs": "^6.26.2",
    "babel-preset-env": "^1.7.0",
    "babel-preset-es2015": "^6.24.1",
    "babel-preset-jest": "^23.2.0",
    "babel-preset-react": "^6.24.1",
    "babel-preset-stage-2": "^6.24.1",
    "babel-runtime": "^6.26.0",
    "cache-loader": "^1.2.5",
    "canvas": "^2.1.0",
    "deploy-to-git": "^0.1.5",
    "enzyme": "^3.7.0",
    "enzyme-adapter-react-16": "^1.7.0",
    "enzyme-to-json": "^3.3.4",
    "http-parser-js": "^0.5.0",
    "http-proxy-middleware": "^0.19.0",
    "imports-loader": "^0.8.0",
    "install": "^0.12.2",
    "node-sass": "^4.10.0",
    "normalize.css": "^8.0.1",
    "npm": "^6.4.1",
    "npm-check": "^5.9.0",
    "object-assign": "4.1.1",
    "promise": "^8.0.2",
    "react-scripts": "^2.1.1",
    "react-scripts-ts": "^4.0.8",
    "react-test-renderer": "^16.6.1",
    "resolve-url-loader": "^3.0.0",
    "rimraf": "^2.6.2",
    "source-map-explorer": "^1.5.0",
    "source-map-loader": "^0.2.1",
    "sw-precache-webpack-plugin": "^0.11.5",
    "thread-loader": "^1.2.0",
    "ts-jest": "^23.10.4",
    "ts-loader": "^5.3.0",
    "tslint": "^5.11.0",
    "tslint-config-prettier": "^1.10.0",
    "tslint-react": "^3.6.0",
    "typescript-babel-jest": "^1.0.5",
    "typings-for-css-modules-loader": "^1.7.0",
    "whatwg-fetch": "^3.0.0",
    "worker-loader": "^2.0.0"
  }
}

[email protected] has released. when using typings-for-css-modules-loader, we receive an error css-loader/locals was dropped in favor exportOnlyLocals option

In my project, i use style-loader, typings-for-css-modules-loader, post-css, less-loader;

The question is :
if i run my project, the page shows correctly, and css has come in to my Dom correctly with
moduled names;
however, in my IDE, the code "import style from './xxx.module.less"still show -- "TS2307 cannot find module"

if typings-for-css-modules-loader is wrapper from css-loader, and need style-loader , in my option, it create d.ts at run time, and inject in to html script, so maybe IDE's warning is obvious .... but in html i did't see any related script;

i am a newbie to TS..
is there anything i missed in docs or am i get something wrong ?

I am using tslint and It shows me error because indent and quote statically defined and scss.d.ts definition files shows me errors. This options should be customizable.

Since you have created a Webpack loader for the same, isn't it possible to create a simple cli tool that will create the typings (without using webpack).

This way you can run the tool first and then run the webpack project/build. Solves one of your known issues:

Typescript doesnt find the typings
As the webpack process is independent from your typescript "runtime" it may take a while for typescript to pick up the typings. Any hints on how this could be fixed deterministically are welcome!

We have successfully introduced this package into our project and typings are generated just fine. However a problem arose on our build server because the first time when the project is compiled with webpack the typing files aren't generated yet causing the typescript compilation to fail.

Are we doing something wrong? Is there any way to fix it?

Here's our module config:

module: {
    rules: [
        { test: /\.scss$/, use: ["style-loader", { loader: "typings-for-css-modules-loader", options: { modules: true, namedExport: true, camelCase: true, localIdentName: "[path][name]__[local]--[hash:base64:5]" } }, "sass-loader"] },
        { test: /\.tsx?$/, use: [{ loader: "ts-loader", options: { transpileOnly: true } }] }
    ]
},

At least in my opinion,

plugins: [
    new webpack.WatchIgnorePlugin([
      /css\.d\.ts$/
    ]),
    ...
  ]

isn't the correct way to resolve this problem. In my case when I appended that line, it started to ignore *.css.d.ts files completely (sounds obvious, but read on). Which meant that, once typings-for-css-modules-loader created the typings definition file, Webpack didn't recompile! So whenever I added a new class in the css file, I got an error. It didn't occur if I changed an attribute inside a preexisting class since the typings definition for it already existed.

The correct way would be to not make Webpack ignore those files at all! What you could do is, run a sequential task and generate the typings defs before starting webpack using something like this.

But even then you do get an error once a new class has been added. The pass that generates the error is also responsible for creating the typings def file, and when that happens, webpack realizes that a change has been made to one of the files and recompiles, but this time it's a success! 😁

If I have a simple foo.scss:

.shell {

    &.path {
        background: linear-gradient(to right, #17202A, #212F3D);
    }

}

using webpack.config.js:

module: {
    rules: [
        {
            test: /\.scss$/,
            use: extractTextPlugin.extract({
                fallback: "style-loader",
                use:
                    isDevBuild
                        ? "typings-for-css-modules-loader?modules&namedExport&camelCase&localIdentName=[name]_[hash:base64]&sass"
                        : "typings-for-css-modules-loader?modules&namedExport&camelCase&localIdentName=[name]_[hash:base64]&sass&minimize"
            })
        },
    ]
},
plugins: [
    ...
    new extractTextPlugin("site.css")
]

I get (wrong) site.css output:

.Shell_2QRiEglvWZ4mcPjp67mAja {

    &.Shell_3D4R68K4RPOKDY6fLBEteJ {
        background: linear-gradient(to right, #17202A, #212F3D);
    }

}

I expected to see something like:

.Shell_2QRiEglvWZ4mcPjp67mAja.Shell_3D4R68K4RPOKDY6fLBEteJ {
    background: linear-gradient(to right, #17202A, #212F3D);
}

Is this issue with my configuration or issue with typings-for-css-modules-loader?

Great module, and I got it working easily enough.

I'm currently importing the class names from bootstrap.less, and one of the classes is called in.

'in' is a reserved keyword and so causes a validation error in the bootstrap.less.d.ts file.

I had a look through the options, but there didn't appear to be an option that addresses this issue.

My 'webpack.config.js' section FWIW:

{
    loader: 'typings-for-css-modules-loader',
    options: {
        modules: true,
        namedExport: true,
        camelCase: true,
        sourceMap: true
    }
},

One can create plugins for tsc to run it during compilation: https://github.com/Microsoft/TypeScript/wiki/Writing-a-Language-Service-Plugin

Is it possible to add a banner at the beginning of the generated files?

Something like
/* This file is automatically generated. Do not modify this file manually -- YOUR CHANGES WILL BE ERASED! */

Currently it doesn't seems that there is a such an option.

Thank you for this great module.
With css-loader I can include css-loader/locals to only export the classnames and not embed them in the bundle. How would I do that in this module?

currently I have the following in my webpack config:

...
loader: server ? "css-loader/locals" : "css-loader",
    options: {
      modules: true,
      importLoaders: !server,
      localIdentName: "[name]__[local]--[hash:base64:5]"
    }
...

When i use typescript 2.4 and the latest typings-for-css-modules-loader, it will convert sass file as follow:

sytle.sass：

$font-stack:    Helvetica, sans-serif
$primary-color: #333

.some-class
  font: 100% $font-stack
  color: $primary-color

to style.sass.d.ts:

export interface IStyleSass {
  'some-class': string;
}

export const locals: IStyleSass;

so, in the ts file, when I import it as follow:

import style from './styles.sass'

error occurs:

error TS1192: Module '"xxxxx/xxxx/src/style.sass"' has no default export.

so, it should be imported as following:

import * as styles from './style.sass';

then, it works!

As the title says, using the loader to generate .d.ts files in combination with webpack's watch mode runs in an endless cycle of the .d.ts files being generated, then triggering the webpack file-watchers and running the webpack compilation again over and over.

When I declare a global block, no .d.ts declaration is emitted for it. The CSS does get written into the final file, however. This means that I get an error when trying to refer to my global style in TypeScript. Is this expected behaviour?

Input SCSS

One global block and one default block (default is local).

:global {
    .fullscreen {
        position: absolute;
        left: 0px;
        top: 0px;
        width: 1280px;
        height: 720px;
    }
}

.justify_content_space_around {
    -webkit-justify-content: space-around;
    justify-content: space-around;
}

Typescript invocation

import { locals } from '../scss/generic.scss';

// No compiler problems with the local one:
console.log(locals.justifyContentSpaceAround);

// [ERROR] TS2339: Property 'fullscreen' does not appear on type 'IGenericScss'
console.log(locals.fullscreen);

Generated .d.ts file

Note that the global 'fullscreen' style does not get generated, and only a 'locals' property is exported (I was expecting perhaps to see a 'globals' too). Is that expected behaviour?

export interface IGenericScss {
  'justify_content_space_around': string;
  'justifyContentSpaceAround': string;
}

export const locals: IGenericScss;

Output CSS

You'll see from the below Webpack settings that I have 'minimize' set to true, but I've pretty-printed it here for legibility.

.fullscreen{
    position: absolute;
    left: 0;
    top: 0;
    width: 1280px;
    height: 720px
}
.BgmO{
    -webkit-justify-content: space-around;
    justify-content: space-around;
}
/*# sourceMappingURL=project.css.map*/

Webpack config

{
    test: /\.scss$/,
    include: [ path.resolve(__dirname, "../src/scss") ],
    use: ExtractTextPlugin.extract({
        use: [
            {
                loader: 'typings-for-css-modules-loader',
                options: {
                    namedexport: true,
                    camelcase: true,
                    modules: true,
                    localIdentName: '[hash:base64:4]',
                    minimize: true,
                    importLoaders: 2
                }
            },
            {
                loader: 'postcss-loader',
                options: {
                    plugins: function () {
                        return [ autoprefixer({browsers: ["since 2013"]}) ]
                    }
                }
            },
            {loader: 'sass-loader', options: {}}
        ],
        fallback: 'style-loader'
    })
};

When working with css, my set of rules looks like this:
{ test: /\.css$/, loader: "style-loader"},
{ test: /\.css$/, loader: "typings-for-css-modules-loader?modules&namedExport" }
and it works as expected.
Trying to change to scss, I added the line:
{ test: /\.scss$/, loader: "typings-for-css-modules-loader?modules&namedExport&sass" }
after the 2 previous ones, and while the modules are properly exported, style-loader is not loading any style.

Is this package incompatible with style-loader or am I doing something wrong?

Is there any option to have the generated *.css.d.ts files put in a specific folder and not alongside the css file? like /src/typings/styles ?

I'm using typings with the sass and style loaders (config below); running into a weird problem where classnames only seem to be accessible in object[key] form:

styles.scss

.workflow { background: white; }

Generated styles.scss.d.ts

export interface IStylesScss {
  'workflow': string;
}

export const locals: IStylesScss;

index.tsx

import * as styles from './styles.css';

console.log(typeof styles); // object
console.log(styles.hasOwnProperty('workflow')); // true
console.log(styles['workflow']); // HRFVrY_1Hckr-wLNbdHq5
console.log(styles.workflow); // Error

export class Workflow extends React.Component<{}, {}> {
    render() {
        console.log(styles.workflow); // Error
        return <div className={styles['workflow']}>...</div> // Works
    }
}

Accessing the className like styles['workflow'] works fine, but accessing by property will give you this error:

[tsl] ERROR in .../index.tsx(22,24)
      TS2339: Property 'workflow' does not exist on type 'typeof ".../styles.scss"'.

I'm relatively new to TS, so sorry if this is a TS quirk/problem. I'm also using the ts-loader for TS.

tsconfig.json

{ "compilerOptions": { "jsx": "react" } }

scss loader

{
  test: /\.scss$/,
  use: [
    { loader: 'style-loader' },
    {
      loader: 'typings-for-css-modules-loader',
      options: {
        modules: true
      }
    },
    { loader: 'sass-loader' }
  ]
},

versions

"ts-loader": "^3.5.0",
"typescript": "^2.7.1",
"typings-for-css-modules-loader": "^1.7.0",

Would it be possible to configure where the declaration files are written?
This would help de-clutter folders with the source code and would make it easy to git ignore the generated files.

If I create a simple file to hold my color variables, let's say:

variables.scss

$color-vue-green: #42b883;
$color-vue-navy: #35495e;

The output is empty,
variables.scss.d.ts

export interface IVariablesScss {

}

export const locals: IVariablesScss;

Whereas I was hoping for it to include:

export interface IVariablesScss {
     colorVueGreen: string;
     colorVueNavy: string;
}

export interface ITest {
  'icon-test': string;
  'iconTest': string;
}

When using camelCase without namedExports, the interface contains both camelcase and hyphenated class names. My expectation is if I specified camelCase it would not include hyphenated class names.

Is this a bug? If not, can we do something to alter the behavior to not include the hyphenated classes?

Note that I specifically am not using namedExports so I can use the "keyof" functionality of TypeScript to validate strings against the interface.

First of all thank you very much for your loader! 👍 💯
If you could make it a vs code extension which supplies some configurations that control the css typings generation behavior to avoid the webpack rebuilds / builds slow problem?
For example:

"generate-typings-for-css-on-save" : true

and when editing the (s)css file and save the file, the typings file auto generated silently.

Or if you could make this loader features as a part of the SASS extension for vs code?

Hope for your good news! Thanks again!

The final output that the type definitions are supposed to match is very fragile.

E.g.

loaders: ['typings-for-css-modules-loader?sourceMap&modules'] creates an export of the css like

exports.locals = { "foo": "foo-1A72" }

which is not the exports.default that the definition expect.
loaders: ['style', 'typings-for-css-modules-loader?sourceMap&modules&importLoaders=1'} creates an export of the css like

exports.foo= "foo-1A72"

which I expected to be an object on exports.default but instead got the same behaviour as if namedExport was defined. See webpack/style-loader#local-scope-css and webpack-contrib/style-loader#77

I think changing the export from default to locals is correct and adding to the readme that style-loader requires namedExport. I've made some of those changes and fixed some others in my fork

I have a file main.scss, it has the following sass
md-chips.md-chips { padding: 0 0 3px 3px; }

Once it compiles it comes out to md-chips._1hUKVVrEWX03XfZGvyCZ-M { padding: 0 0 3px 3px; }

Here is my webpack.config.js rule

{
  test: /\.scss$/,
  use: ExtractTextPlugin.extract({
      use: [
          {
              loader: 'typings-for-css-modules-loader',
              options: {
                  modules: true,
                  namedExport: true,
                  camelCase: true,
                  sourceMap: true
              }
          },
          {
              loader: 'sass-loader',
              options: {
                  sourceMap: true,
                  namedExport: true
              }
          }]
  })
}

I'm using webpack 3.6.0, i'm unsure if it is not supported here or if it could be something else?

I'm giving this a shot but it doesn't seem to be working. I'm not sure what I'm missing, I dropped in this loader in place of css-loader as instructed.

I'm using WebPack 2 (webpack-dev-server) and TypeScript 2.2.1. Here's my loader config:

        test: /\.s?(a|c)ss$/,
        use: [
          'style-loader',
          // { loader: 'css-loader', options: { sourceMap: true, importLoaders: 3 } },
          { loader: 'typings-for-css-modules-loader', options: { sourceMap: true, importLoaders: 3, modules: true, namedExport: true, camelCase: true } },
          { loader: 'postcss-loader', options: { sourceMap: true } },
          { loader: 'resolve-url-loader', options: { sourceMap: true, root: path.resolve(__dirname, 'client') } },
          { loader: 'sass-loader', options: { sourceMap: true } }
        ] 

app.ts:

import style from './app.scss';

app.scss:

.app {
  color: red;
}

Two things to note, in order for TypeScript to load .scss files as modules, I added this to the custom-typings.d.ts file in my source folder:

declare module '*.scss' {
  const _: string;
  export default  _;
}

Anyway, not getting any .d.ts files, not getting any output in my console regarding this loader as far as I can tell, and not getting any types from my sass files. I'd think because I'm aliasing the .scss import as a string, it wouldn't work, so I'm curious if there's a different/better way to do that too.

Thanks!

Hi folks, I'm using awesome-typescript-loader and webpack v4.21.0, I'm running into the following scenario:

1. run webpack-dev-server -w
2. dev server serves up content
3. css .d.ts files get generated
4. typescript compiler complains that type for styles do not exist (even though interface files are present)
5. even if I make changes to my css or ts files, the interfaces do not get picked up by webpack -watch, despite webpack watch is picking up other ts changes

Here are how my rules get setup in webpack:

    rules: [
      {
        test: /\.css$/,
        // include: [path.resolve(__dirname, 'src'), path.resolve(__dirname, '..', '..', 'packages')],
        exclude: /node_modules/,
        enforce: 'pre',
        use: [
          {
            loader: 'style-loader'
          },
          {
            loader: 'typings-for-css-modules-loader',
            options: {
              modules: true,
              namedExport: true,
              camelCase: true,
              localIdentName: '[name]__[local]--[hash:base64:5]'
            }
          },
          {
            loader: 'postcss-loader'
          }
        ]
      },
      { test: /\.tsx?$/, enforce: 'post', loader: 'awesome-typescript-loader' }
    ]

I have attempted enforce: "pre" rule to get typings-for-css-modules-loader to run before awesome-typescript-loader but doesn't do the trick.

Wondering if anyone else has run into similar situation before or can offer any ideas? Many thanks

Classnames starting with a number [0-9] cause a syntax error in the generated .css.d.ts file.

An example is the classname 35 00px in SemanticUI which results in the type definition export const 35: string;, which obviously throws syntax errors.

A fix is to change the allWordsRegexp to /^[a-zA-Z]\w*$/i. Although no idea if that's the best approach.