Module build failed: TypeError: this.getOptions is not a function

–Sage10.–

Finds out this is sage 9

When I do ‘yarn start’, I get this issue:

error in ./resources/assets/styles/main.scss

Module build failed: TypeError: this.getOptions is not a function
at Object.loader (/Users/Dorota/Desktop/WebDev/0Client/WordPress-System/wp-content/themes/wordpress-system-demo/node_modules/postcss-loader/dist/index.js:38:24)

@ ./resources/assets/styles/main.scss 2:14-355 21:1-42:3 22:19-360
@ multi ./resources/assets/build/util/…/helpers/hmr-client.js ./scripts/main.js ./styles/main.scss

The main file looks like this:

   @tailwind base;
   @tailwind components;
   @tailwind utilities;
   //@import "components/buttons";

And I’ve tried to install uninstall, do X and do Y, but I can’t seem to make this work

Not sure what to do at this point.

Are you using Sage 9 or 10? For Sage 9 there is an update branch that should fix all the build issues:

Sage10.

Yeah, I know. I used that one. So I assume its best to use Sage 9, since Sage 10 is too broken.

So I tried to build this with Sage 10 and it just works fine.

  1. composer create-project roots/sage your-theme-name dev-master
    (y)
  2. cd your-theme-name
  3. nvm use lts/* && npm install -g npm
  4. npm install
  5. (Put the styles you posted about into resources/styles/app.scss).
  6. npm run build

If you are wondering what nvm is, well, it is a node version manager tool (there are also others but I prefer this one): https://github.com/nvm-sh/nvm. lts/* means that the latest LTS node version branch should be used which is maintained for long times and should be very stable. npm install -g npm self-upgrades npm as with node often an outdated npm is shipped. This can also alleviate lots of issues.

What OS are you using? OS X? Windows? Linux?

1 Like

I’m slightly confused.

I’m using ‘v14.16.0’ Long term support, right.

Currently mac OS Mojave - 10.14.6. However, in a week I’d be using Windows.

Why do we put it in app.scss? Since app.scss doesn’t exist, so we need to change the main.scss into app.scss, does it change if we re-name the folder name?

I’m sure I’ve did what you said, but that doesn’t seem to work.

Ah, I see. I assumed that you are using Sage 10 now. Well, apparently you use Sage 9.x update branch.
If it work fine with Sage 10 you should use it. So try this again with Sage 10.

Also update npm using npm install -g npm.

1 Like

I am using Sage 10 the whole time on this threat.

WAIT! I am NOT! I just checked package.json… It says " “version”: “9.0.10”," - men, this is so confusign! Why don’t they update their docs?!

So I though I was using Sage 10. It finds out I wasn’t xd

This is so frustrating xd

Let me… alwaysblank says its sage 10… What version of sage is a reliable one?

So is this sage 10 named as 9,0,10 or sage 9?

I’m soo confused.

I don’t know what am even looking at now.

When you create a new sage project using composer (the recommended approach) you can either install 9 or 10.

For 9 without update branch you can use this command:
composer create-project roots/sage your-theme-name

For 9 update branch (the GitHub repo for the update branch that hadn’t been merged yet):
composer create-project roots/sage your-theme-name dev-webpack5 --repository='{"type":"vcs","url":"https://github.com/strarsis/sage"}'

For Sage 10 you use dev-master:
composer create-project roots/sage your-theme-name dev-master

So I would recommend that you create a new Sage 10 project using the command above and then copy your styles over (if there are any yet) and try building it there.

1 Like

Awesome! Thank you soo much!

It seems it works! I like that it has TailwindCSS as default too :slight_smile:

Now I can finally rock. Hopefully. Hopefully, it will work on windows, but with WSL I should be just fine right?

Yes, I use Sage 9 and Sage 10 on WSL 2 on a regular basis, for two years or so.
I use WSL 2 Ubuntu 20.x LTS on Windows 10.
You can even install it directly as an “app” using the Microsoft Store.

Edit: Hm, one thing though: Although WSL 2 got much better compatibility with Docker and Vagrant,
WSL 1 currently got faster I/O for accessing the host disks. So when you are using WSL 2, for increased performance, you should put your files onto ~/src. I am also using a self-hosted GitLab for my code, so I can just push/clone from it anyway.

https://roots.io/docs/getting-started/windows/#working-with-trellis

1 Like

This topic was automatically closed after 42 days. New replies are no longer allowed.