Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[v6.0.0] TypeError: this.getOptions is not a function #631

Closed
korbav opened this issue Nov 29, 2021 · 19 comments · May be fixed by GabrielNathan12/to-do-list-agent#49 or GabrielNathan12/to-do-list-agent#51
Labels

Comments

@korbav
Copy link

korbav commented Nov 29, 2021

🐛 Bug Report

Last release v6.0.0 provoked the following issue : TypeError: this.getOptions is not a function

Which is referring to the following call:

function svgrLoader(
this: webpack.LoaderContext<LoaderOptions>,
contents: string,
): void {
this.cacheable && this.cacheable()
const callback = this.async()
const options = this.getOptions()
const previousExport = (() => {
if (contents.startsWith('export ')) return contents
const exportMatches = contents.match(/^module.exports\s*=\s*(.*)/)
return exportMatches ? `export default ${exportMatches[1]}` : null
})()

To Reproduce

Steps to reproduce the behavior:

  • Compile any React 17 web project

Expected behavior

The compilation process fails and throws an exception :

Failed to compile. TypeError: this.getOptions is not a function

This unexpected behavior appeared right after upgrading to v6.0.0, it is most likely related to an incompatibility issue with the 3.0.0+ version of loader-utils which brought the following breaking change :

removed getOptions in favor loaderContext.getOptions (loaderContext is this inside loader function), 
note - special query parameters like ?something=true is not supported anymore, 
if you need this please do it on loader side, but we strongly recommend avoid it, as alternative you can use ?something=1 and handle 1 as true
@open-collective-bot
Copy link

Hey @korbav 👋,
Thank you for opening an issue. We'll get back to you as soon as we can.
Please, consider supporting us on Open Collective. We give a special attention to issues opened by backers.
If you use SVGR at work, you can also ask your company to sponsor us ❤️.

@arnriu
Copy link

arnriu commented Nov 29, 2021

I have exact same problem. Going back to 5.5.0 fixed it for now.

@gregberge
Copy link
Owner

Hello, the new loader is only compatible with webpack 5, please upgrade or stay in v5.x.

@korbav
Copy link
Author

korbav commented Nov 29, 2021

Hello, the new loader is only compatible with webpack 5, please upgrade or stay in v5.x.

Hello @gregberge , Actually I'm already using Webpack 5 : npm view webpack :

image

@gregberge
Copy link
Owner

Hello @korbav, it is weird, I let it opened, waiting for other feedback, feel free to investigate it further.

@gregberge gregberge reopened this Nov 29, 2021
@korbav
Copy link
Author

korbav commented Nov 29, 2021

Hi @gregberge ,

According to the fact we are explicitly using loader-utils@^2.0.0

"loader-utils": "^2.0.0"

We should not refactor anything based on the breaking changes introduced by loader-utils@v3.0.0, and in particular this one :

`## 3.0.0 (2021-10-20)

⚠ BREAKING CHANGES

  • removed getOptions in favor loaderContext.getOptions (loaderContext is this inside loader function), note - special query parameters like ?something=true is not supported anymore, if you need this please do it on loader side, but we strongly recommend avoid it, as alternative you can use ?something=1 and handle 1 as `true``

We are explicitly following the previous instruction (which should be implemented only on ^3.0.0) :

function svgrLoader(
this: webpack.LoaderContext<LoaderOptions>,
contents: string,
): void {
this.cacheable && this.cacheable()
const callback = this.async()
const options = this.getOptions()

So my guess would be to step back and to use the previous way of getting the options :

var loaderUtils = require('loader-utils');

function svgrLoader(contents) {
  // ...
  const options = loaderUtils.getOptions(this);
  // ...

@gregberge
Copy link
Owner

Since loader-utils is not required any more, we should just remove this package. I would rather prefer to follow the new recommendation on 3.0.0.

@korbav
Copy link
Author

korbav commented Nov 30, 2021

Since loader-utils is not required any more, we should just remove this package. I would rather prefer to follow the new recommendation on 3.0.0.

If loader-utils is no longer required that sounds quite good to me.
I just cloned the repo, removed it and rebuilt the lib to give it a try, but it seems the same exception is being thrown.

@gregberge
Copy link
Owner

@korbav very weird, because actually tests are passing in the project

@gregberge
Copy link
Owner

@korbav what is your setup?

@korbav
Copy link
Author

korbav commented Nov 30, 2021

@korbav what is your setup?

I'm using npm@v7.21.1 node@v16.9.1 and React 17.0.2 without having ejected the webpack config.

Investigating it a bit more, it seems that getOptions is available through the NormalModule

image

Would it be possible that somehow the test version feeds whatever it needs to compile and prod version doesn't?

Edit: Just checked with the v6.1.0, still the same issue

@korbav
Copy link
Author

korbav commented Dec 2, 2021

Hello @gregberge , I finally understood what was going on.
create-react-app, which is used to compile React apps, is using webpack 4 behind the scene, so even if I had webpack 5 dependency explicitly set on my own package.json, it was not used during the compilation.
I had to upgrade create-react-app to @next which is being developed upon webpack 5.
The final word is svgr is perfectly fine and we can definitely close this issue.

@korbav korbav closed this as completed Dec 2, 2021
@gregberge
Copy link
Owner

Good to hear, thanks!

@o-mega
Copy link

o-mega commented Dec 9, 2021

I had the same issue here while trying to use svgr with @storybook/react@^6.4.9.
The storybook's docs said it fully upgraded to webpack@5 , but I still see webpack@4 references in my .lock file

@hi-paul
Copy link

hi-paul commented Dec 10, 2021

same issue. I also use @storybook/react@^6.4.9

@korbav
Copy link
Author

korbav commented Dec 10, 2021

I had the same issue here while trying to use svgr with @storybook/react@^6.4.9. The storybook's docs said it fully upgraded to webpack@5 , but I still see webpack@4 references in my .lock file

same issue. I also use @storybook/react@^6.4.9

This is not surprising, they have an explicit dependency to webpack 4 in the package.json :

https://github.com/storybookjs/storybook/blob/3e5d6601ba3de7e1d6bd64bca97917dc9d40244b/package.json#L282

I would advise either not to upgrade svgr for the moment, or to create an issue/discussion on storybook to figure out what they plan to upgrade to webpack 5.

@hi-paul
Copy link

hi-paul commented Dec 11, 2021

@korbav Thanks for your explanation👍

@alexandrtovmach
Copy link

Can be solved by forcing storybook to use webpack 5:
https://storybook.js.org/blog/storybook-for-webpack-5/

MH4GF added a commit to MH4GF/log.mh4gf.dev that referenced this issue May 4, 2022
gregberge/svgr#631 を解決するためにはwebpack5にあげれば良いとのこと
EnzoVezzaro added a commit to oceanprotocol/market that referenced this issue May 9, 2022
using the latest version introduces this [issue](gregberge/svgr#631)
@kaili-yang
Copy link

kaili-yang commented Apr 7, 2023

Hey, I just new a question on Stackoverfolow.
Is "this.getOptions is not a function" a bug for webpack?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
7 participants