WebPack loader

[texastoland]

Have you consider making this a WebPack loader so it can work on any transformed CSS (we're using cssnext)?

[Quramy]

Hi @AppShipIt . I don't plan it for now.

I created this tool to help TypeScript coding. It means that I need *.css.d.ts before bundling my app.

[texastoland]

That's what we're doing too it's just not vanilla CSS. I'll close and get around to it myself eventually 👍

[olegstepura]

Hi! FYI: I've written a simple webpack loader: https://www.npmjs.com/package/typed-css-modules-loader

[texastoland]

I'll give it a try within the next few days 🙌

[athyuttamre]

@AppShipIt did you ever get it working? I'm using css-next with TypeScript and this too.

[texastoland]

olegstepura/typed-css-modules-loader#1 (comment): TL;DR I think typed-css-modules needs to be a PostCSS plugin (it's a dependency anyway) to play nice with other PostCSS plugins.

[athyuttamre]

@AppShipIt Actually, I was able to make it work with PostCSS and any other loader.

What you want to do is put this loader between css-loader and all other loaders (postcss, sass etc.) That way the later loaders will process your files, generating plain CSS, then this loader will generate the .d.ts files, then css-loader will do its job.

Here's what my setup looks like:

// typed_css_module_loader.js

// Note: not the version from npm, slightly modified to operate on the `source` variable
// rather than the file itself. This way it operates on the CSS handed down to it by any
// preceding loaders.
var DtsCreator = require('typed-css-modules');
var creator = new DtsCreator();

module.exports = function(source, map) {
  this.cacheable && this.cacheable();
  var callback = this.async();

  // creator.create(..., source) tells the module to operate on the
  // source variable. Check API for more details.
  creator.create(this.resourcePath, source).then(function(content) {
    content.writeFile().then(function() {
      callback(null, source, map);
    });
  });
};

// webpack.js

var compiler = webpack({
  .
  .
  .
  module: {
    .
    .
    .
    loaders: [
        // Load CSS modules
        { test: /\.css$/,
          loader: ExtractTextPlugin.extract(
            "style",
            "css?modules&localIdentName=[name]--[local]&sourceMap!typed-css-modules!postcss"
          )
        }
    ]
    .
    .
    .
  }

  .
  .
  .
  resolveLoader: {
    root: path.resolve(__dirname, "node_modules"),
    alias: {
      "typed-css-modules": path.resolve(__dirname, "loaders/typed_css_modules_loader")
     }
  }
)};

[athyuttamre]

The one issue I'm running into is that the file creation is asynchronous. The implication is that when you create a new file, its possible that the TypeScript compiler runs before the .d.ts files are generated, which makes the compiler complain. The next time webpack runs everything is ok, but there's an error the first time after a new file is created.

[athyuttamre]

Actually, I'll take that back. The issue still holds, but probably isn't because of synchronous/asynchronous file generation. It probably has something to do with webpack's conception of the filesystem i.e. if you generate a file using a loader, subsequent loaders don't know about it until the next time webpack runs.

[olegstepura]

@athyuttamre

The one issue I'm running into is that the file creation is asynchronous. The implication is that when you create a new file, its possible that the TypeScript compiler runs before the .d.ts files are generated, which makes the compiler complain. The next time webpack runs everything is ok, but there's an error the first time after a new file is created.

I experience the same issue with https://github.com/olegstepura/typed-css-modules-loader
We all need a bulletproof solution ;)

I tried to solve that issue using my loader as a preloader, but it wasn't much helpful. I still need to reload project from time to time when I change/create css files.

Actually your comment has exact code that I have in my loader. I've changed it to use second argument in creator.create

[athyuttamre]

Yep, looks like we're in the same boat @olegstepura. I'll post here if I figure it out though!

My plan is to see if I can hijack the _compiler or _compilation object and modify the filesystem in there. That way we can put our CSS loaders in preLoaders, which will add the new type definitions into the filesystem cache. Then in actual loaders when TS compiler runs, it'll see the files existing.

[texastoland]

I still suspect this needs to a PostCSS plugin instead of wrapping it. I'd be happy to help and test.