debens / gatsby-plugin-scss-typescript Goto Github PK

Trying to work out why a non hashed css filename gets generated:

styles.css

alongside the hashed version

You can see this here:

https://www.bristol.ac.uk/people-dev/webpack-runtime-fe8f04404ec56e2b89c5.js

i've managed to resolve this by passing cssExtractptions

      resolve: 'gatsby-plugin-scss-typescript',
       options: {
        cssExtractOptions: {
          filename: '[name].[contenthash].css',
          chunkFilename: '[name].[contenthash].css',
        },
      },
    },

which stops the styles.css from being generated.

THe issue that has manifested is some users are getting an old cached version of styles.css as gatsby states css files need a long cache time. This is an issue when using the offline plugin and service workers as the index page thats cached uses a cached version of a stylesheet (in this case styles.css)

What would it be generating this non hashed file by default when all CSS files should be hashed due to caching header settings

Using
gatsby-plugin-scss-typescript": "^5.1.0",
"gatsby": "^3.6.2",

node-sass v5.0.0 is out since the 27th of October.

The gatsby-plugin-scss-typescript shows the warning:

[email protected] requires a peer of node-sass@^4.5.0 but none is installed. You must install peer dependencies yourself.

The build process fails with

undefined failed

Node Sass version 5.0.0 is incompatible with ^4.0.0.

I'm not sure if this plugin is the source of the issue, but even if not, would it be possible to get it updated to support node-sass 5.0.0?

Love the plugin. But I could not get an autoprefixer "easily" working. So I had to scrap using it and do a global generic type function for .scss files.

Any chance you can add autoprefixing?

Unable to resolve jpg files in production.

gatsby-config.js


module.exports = {
  siteMetadata: {
    title: `Gatsby Default Starter`,
    description: `Kick off your next, great Gatsby project with this default starter. This barebones starter ships with the main Gatsby configuration files you might need.`,
    author: `@gatsbyjs`,
  },
  plugins: [
    `gatsby-plugin-react-helmet`,
    {
      resolve: `gatsby-source-filesystem`,
      options: {
        name: `images`,
        path: `${__dirname}/src/images`,
      },
    },
    `gatsby-transformer-sharp`,
    `gatsby-plugin-sharp`,
    {
      resolve: `gatsby-plugin-manifest`,
      options: {
        name: `gatsby-starter-default`,
        short_name: `starter`,
        start_url: `/`,
        background_color: `#663399`,
        theme_color: `#663399`,
        display: `minimal-ui`,
        icon: `src/images/gatsby-icon.png`, // This path is relative to the root of the site.
      },
    },
    "gatsby-plugin-typescript",
    {
      resolve: "gatsby-plugin-scss-typescript",
    },
    {
      resolve: "gatsby-plugin-react-svg",
      options: {
        rule: {
          include: /\.inline\.svg$/,
        },
      },
    },
  ],
};

it seems to add prefixes even to nested clases. for example

item.module.scss

.cardProduct {
  border: 1px solid green;
  .card-body {
    border: 1px solid red !important;
  }
  .card-image {
    border: 1px solid red !important;
  }
}

in develop mode looking at the served module

.item-module--cardProduct--1h2D3 {\n  border: 1px solid green; }\n  .item-module--cardProduct--1h2D3 .item-module--card-body--2KCQ0 {\n    border: 1px solid red !important; }\n  .item-module--cardProduct--1h2D3 .item-module--card-image--3N0Mn {\n    border: 1px solid red !important; }\n

seems to prefix every class which kind of defeats the point of scss ?

Just wondering when this will support 3.0 upgrade. Right now it's still tied to 2.1.0

Hi, I'm trying this extension out with the hope that when loading any given page, only the styles imported on that page would be included in the HTML. Currently I'm seeing all modules published to all pages.

If it doesn't reduce the size and complexity of the styles, I'm not sure I see a point to using it since the only benefit would be scoping, but that's just a syntactic sugar in the end if there's no real-world benefit to users.

This is probably lack of proper webpack configuration. Can you provide an example that shows how to get the styles to split? I tried your example webpack configs but they don't seem to do the trick.

Thanks!

The production build fails when there are global SCSS files imported.

Minimal repo for reproducing: https://github.com/peteorpeter/gatsby-plugin-scss-typescript-test

The error:

TypeError: Cannot read property 'split' of undefined
at CssModule.nameForCondition (/Users/petejones/projects/livefront/gatsby-plugin-scss-typescript-test/node_modules/mini-css-extract-plugin/dist/index.js:77:39)

It's quite possible that this isn't a bug and the solution is to find the right cssLoaderOptions in gatsby-config.js, but I have not found a combination that works.

I have tried a variety of suggestions from webpack-contrib/mini-css-extract-plugin#156 and elsewhere.

To reproduce, clone this repo and run:

yarn
yarn run build
# 💥 BOOM!

The development build runs without error. Commenting out the import of global.scss removes the error in the production build.

Many thanks for developing this plugin! Even if this (maybe) bug were never resolved I'd work around this to keep using typed SCSS modules.

I'm using the Gatsby starter with Wordpress (npm init gatsby and selecting Wordpress). I also installed sass, not node-sass, because LibSass that is used by node-sass has been deprecated.

When I run gatsby develop I get this error when it tries to create the definition files for the SCSS modules:

 ERROR #98123  WEBPACK

Generating development JavaScript bundle failed


        text-align: center;


                                    ^
      Expected "{".
  ╷
2 │ var content = require("!!../../node_modules/typings-for-css-modules-loader/lib/index.js??ref--16-oneOf-0-1!../../node_modules
/postcss-loader/src/index.js??postcss-6!../../node_modules/resolve-url-loader/index.js!../../node_modules/sass-loader/dist/cjs.js
??ref--16-oneOf-0-4!./index.module.scss");
  │

                                         ^
  ╵
  stdin 2:296  root stylesheet
      in /Users/marty/Projects/PHOENIX-HUMAN-PRIME/php-mediathek/src/pages/index.module.scss (line 2, column 296)

File: src/pages/index.module.scss

failed Re-building development bundle - 0.190s

This is really unfortunate. Does this package support sass (Dart Sass)? If not, wouldn't it be right to make it work with it, since it's recommend to use it by the Sass core team.

This is not working at all ?

plugins: gatsby-plugin-scss-typescript,
YES

package.json:
"gatsby-plugin-scss-typescript": "^4.0.10",
"node-sass": "^4.13.1",
YES

import * as styles from "./layout.module.scss"; Nothing happens
erros: Cannot find module './layout.module.scss'.
No .d.ts files are being generated.

Does it work with Gatsby v3? I am trying to use it with the latest version of Gatsby(3.3.0) but The styles are not getting reflected in the DOM.

"gatsby": "^3.3.0",
"gatsby-plugin-scss-typescript": "^5.1.0",
"sass": "^1.32.8"
"gatsby-plugin-typescript": "^3.3.0",
"typescript": "^4.2.4"

I have installed the plugin, converted my *.scss files to *.module.scss and imported them according to the README. Everything worked.

All went great, except that every time I run npm start the plugin generates a *.module.scss.d.ts for each .module.scss file.

I end up having a huge amount of files now, each component looking like

Is this normal? Am I supposed to commit these 100s of *..module.scss.d.ts files? Or should I ignore all of them?
It seems to me like something went wrong...

CSS classnames are removed from the DOM in build (although they still appear in the React DOM). Everything works fine in develop. I'll work on a simple reproduction repo' if needed. :)

Hi, I have your plugin working using Gatsby v3 with no additional options, it works great. Thank you.

First a couple docs suggestions:

• The first line says it's a Gatsby v2 plugin but it's working for me with v3
• You might want to move the addendum about not needing gatsby-plugin-sass up to to Installation, considering that most folks trying to get TS to work with scss modules have already installed that plugin first, then ended up here later.
• Also, you don't make mention of any tsconfig.json settings (target, module, and lib) up top. Works with any?

Second and more importantly though, the section where you mention typescript-plugin-css-modules is confusing. 🤔

• First you ask whether the declaration files are needed and answer with "no", but I don't see any option to not emit them with your plugin. Are you saying you can? How?
• Next you say Well, maybe. [You don't need them. So, why use your plugin?] Then you say You can have type safe css without these declaration files using typescript-plugin-css-modules in your tsconfig.json. So are you saying that can be used as an alternative, or in addition to, your plugin? What benefit does it add? You also show that plugin's recommended way of having a *.scss file, but that's a different approach than generating per-file declarations.
• When I tried that plugin on its own, it didn't work. Even using their VS Code steps, I was unable to get type hinting to work for specific style names as their GIF shows it should, and it also didn't support directly importing styles in curly braces as Gatsby's v3 docs recommend. Again, what are you saying would be the benefit of using both? Or would it be clearer to just have a section that explains that there's a different plugin out there with a different approach and clearly states not to try using it with this one instead of showing us how to do that?

Sidebar: In general if their plugin worked, I'd greatly prefer having one simple .d.ts that pipes style names dynamically using a TS language plugin. That would avoid the clutter and one would hope that clicking a declaration would jump you into the actual scss file, not a typings file. If your plugin was able to the latter, I'd be okay with the clutter part, but just having code hints for style names without click-through to the actual definition feels like half a solution.

(That said, I do appreciate that you at least have something here that works, and with some updates to the docs it might be clearer to me what the interactions with other solutions out there are and more clearly what this one should be expected to do and not do. Thanks again!)

Hi.

Yes, I read the README and I understand that this is for development.

Our development scenario is that we'd like to have our CSS modules typings in our CI/CD environment, without committing them to source control, so that they're available when we're linting and typechecking.

We are using this plugin for development and would love to be able to use it when we're building for production and linting in our CI/CD pipeline, too.

What do you think about an option for telling the plugin to create typings even if the environment is production?

Our scenario would be something like generateTypings: !!process.env.CI || process.env.NODE_ENV !== 'production'

Thanks for an awesome plugin!