You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We use typed-css-modules to generate the corresponding type definitions for each CSS files. Currently this is achieved by a custom Webpack loader, similar to typed-css-modules-loader, after solving a series of issues with many ugly black magics and workarounds:
The loader generated .css.d.ts files will trigger an infinite re-compile loop, then we introduced webpack.WatchIgnorePlugin to tell Webpack watcher ignore those files.
As a consequence of the above change, ts-loader also becomes blind to any generated .css.d.ts files, which causing compile failure. Then we introduced (WatchTimestampsPlugin)[https://github.com/zhenwenc/create-react-app/blob/master/packages/react-scripts/config/WatchTimestampsPlugin.js] to ensure they are still picked up by ts-loader's caching mechanism.
However, the solutions is still imperfect, there are unsolved problems:
After changing a CSS file, an additional compile iteration is required for ts-loader to pickup the change. This is because before the .css.d.ts had been generated, ts-loader already caches all in scope .ts files.
The above problem also causes PROD build and the initial run of DEV build to fail with .css.d.ts files are missing. For that we introduced createTypedCssModules as a workaround, where we generates the type definitions as the first step of the PROD/DEV build pipeline.
After creating a CSS file, we have to manually modify a TS file to trigger the re-compile so that the corresponding .css.d.ts file can be generated. Note that this happens only if this CSS file is referenced by a TS file.
After all these mess, I am wondering does Webpack plugin would play better in this role? As a plugin can hook to many compilation lifecycle, we can easily perform the type definition generating process before the compilation actually starts, so that we always ensure that the latest .css.d.ts files are been loaded by ts-loader.
However, I can't think of any solution for the above problem (5). In addition, should we concern that the generated type definition is not actually based on the final compiled CSS files, this also apply to the PROD build of using loader. With the same reason, migrate to plugin means we cannot support LESS/SASS (why should we care anyway).
The text was updated successfully, but these errors were encountered:
We use typed-css-modules to generate the corresponding type definitions for each CSS files. Currently this is achieved by a custom Webpack loader, similar to typed-css-modules-loader, after solving a series of issues with many ugly black magics and workarounds:
The loader generated
.css.d.ts
files will trigger an infinite re-compile loop, then we introducedwebpack.WatchIgnorePlugin
to tell Webpack watcher ignore those files.As a consequence of the above change,
ts-loader
also becomes blind to any generated.css.d.ts
files, which causing compile failure. Then we introduced (WatchTimestampsPlugin)[https://github.com/zhenwenc/create-react-app/blob/master/packages/react-scripts/config/WatchTimestampsPlugin.js] to ensure they are still picked up byts-loader
's caching mechanism.However, the solutions is still imperfect, there are unsolved problems:
ts-loader
to pickup the change. This is because before the.css.d.ts
had been generated,ts-loader
already caches all in scope.ts
files..css.d.ts
files are missing. For that we introduced createTypedCssModules as a workaround, where we generates the type definitions as the first step of the PROD/DEV build pipeline..css.d.ts
file can be generated. Note that this happens only if this CSS file is referenced by a TS file.After all these mess, I am wondering does Webpack plugin would play better in this role? As a plugin can hook to many compilation lifecycle, we can easily perform the type definition generating process before the compilation actually starts, so that we always ensure that the latest
.css.d.ts
files are been loaded byts-loader
.However, I can't think of any solution for the above problem (5). In addition, should we concern that the generated type definition is not actually based on the final compiled CSS files, this also apply to the PROD build of using loader. With the same reason, migrate to plugin means we cannot support LESS/SASS (why should we care anyway).
The text was updated successfully, but these errors were encountered: