-
-
Notifications
You must be signed in to change notification settings - Fork 429
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
fix: Removed usage of loader-utils #1288
Conversation
@alexander-akait: Is this how you meant? Schema doesn't seem to be optional though: Edit: Something i definitely wrong! 😅 |
emojis-list@^3.0.0: | ||
version "3.0.0" | ||
resolved "https://registry.npmjs.org/emojis-list/-/emojis-list-3.0.0.tgz#5570662046ad29e2e916e71aae260abdff4f6a78" | ||
resolved "https://registry.yarnpkg.com/emojis-list/-/emojis-list-3.0.0.tgz#5570662046ad29e2e916e71aae260abdff4f6a78" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@johnnyreilly Haven't used yarn or a lockfile for a long time. Are these changes okey?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
loader-utils@^1.0.2 is used by babel-loader I think. Probably has something to do with the tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
babel-loader
support old versions of webpack, they drop it in future, ideally we should improve getOptions
on webpack side like: getOptions<T extends object>(schema: any): T;
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's definitely optional: https://github.com/webpack/webpack/blob/85fe6ac4f436384e2a20c7996c70f14e4172ccd8/lib/NormalModule.js#L495
It's our definition in this case that's causing the issue. But I'm fine with that. I'm hoping this will resolve it in future: webpack/webpack#13164
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alexander-akait: If I'm not mistaken you need getOptions<T extends object>(schema?: any): T;
to make it truly optional in strict mode. That's why I had to send in undefined
. I can be wrong here though.
I guess that has something to do with this? |
src/index.ts
Outdated
@@ -646,7 +643,7 @@ function makeSourceMap( | |||
return { | |||
output: outputText.replace(/^\/\/# sourceMappingURL=[^\r\n]*/gm, ''), | |||
sourceMap: Object.assign(JSON.parse(sourceMapText), { | |||
sources: [loaderUtils.getRemainingRequest(loaderContext)], | |||
sources: loaderContext.remainingRequest, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do not change it on string, keep in array, i.e. [loaderContext.remainingRequest]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Of course! Now I feel stupid! 😅
Thanks!
231e43c
to
cc6b1c2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great
Our storybook which is using ts-loader no longer shows any stories after this change.
|
Hi, Thanks for reporting. Can you confirm that |
Verified that ts-loader 9.0.1 works and 9.0.2 does not for our storybook. |
@jamestalton most likely you have two webpack versions, run |
Looks like just
|
@jamestalton: ts-loader 9.x.x is for Webpack >= 5. That's probably why you get the issue! |
I'm getting the following error with ts-loader 9.0.2 or later:
The suggestion at the end does nothing. The same app does work with ts-loader 9.0.1. |
I've got the same issue |
@gligoran, @sandro768: You most probably have webpack@4.x.x in you project. |
Oh, sorry. I've seen that comment about this a bit up and wanted to mention it in mine, but forgot. I was using webpack 4 and upgraded to 5. Here are my relevant devDeps:
If I upgrade to Here's my const path = require('path');
const mode = process.env.NODE_ENV || 'production';
module.exports = {
mode,
entry: './src/index.ts',
target: 'webworker',
module: {
rules: [
{
test: /\.tsx?$/,
loader: 'ts-loader',
options: {
transpileOnly: true,
},
},
],
},
resolve: {
extensions: ['.ts', '.js'],
},
output: {
filename: `worker.js`,
path: path.join(__dirname, 'dist'),
},
}; Could this be a problem with upgrading from 4 in terms of old config style? |
@gligoran run |
Here's what that returns (just updated to the newest version of webpack):
I also ran this, if there's any other webpack stuff that might lend a better insight:
|
@gligoran What is the error? |
I've posted it here: #1288 (comment) Or is this not detailed enough? If so, how can I provide more info? |
@gligoran do you use |
It seems that wrangler replaces the installed webpack version. So, it seems we're still running webpack 4 regardless of what's installed in the repo itself. |
UpdateWow. So, while I did have Webpack 5 installed, something else had installed webpack 4 and a higher level folder. |
Upgrade to v5.x using `vue upgrade --next`. Update `vue.config.js` to import and use `defineConfig`, because it provides type safety and created by Vue CLI 5 as default. Vue CLI 5.x upgrades from webpack 4 to 5. It causes some issues that this commit attemps to fix: 1. Fail due to webpack resolving of Ace. Third-party dependency (code editor) Ace uses legacy `file-loader` for webpack resolving. It's not supported in webpack 5. So change it with manual imports. Refs: ajaxorg/ace-builds#211, ajaxorg/ace-builds#221. 2. Wehpack drops polyfilling node core modules (`path`, `fs`, etc.). Webpack does not polyfill those modules by default anymore. This is good because they did not need browser polyfilling as they are used in desktop version only and resolved already by Electron. To resolve errors (using webpack recommendations): - Add typeof check around `process` variable. - Tell webpack explicitly to ignore used node modules. 3. Fail due to legacy dependency of vue-cli-plugin-electron-builder. This plugin is used for electron builds and development. It still uses webpack 4 that leads to failed builds. Downgrading `ts-loader` to latest version which has support for `loader-utils` solves the problem (TypeStrong/ts-loader#1288). Related issue: nklayman/vue-cli-plugin-electron-builder#1625 4. Compilation fails due to webpack loading of `fsevents` on macOS. This happens only when running `vue-cli-service test:unit` command (used in integration tests and unit tests). Other builds work fine. Refs: yan-foto/electron-reload#71, nklayman/vue-cli-plugin-electron-builder#712, nklayman/vue-cli-plugin-electron-builder#1333
Upgrade to v5.x using `vue upgrade --next`. Update `vue.config.js` to import and use `defineConfig`, because it provides type safety and created by Vue CLI 5 as default. Vue CLI 5.x upgrades from webpack 4 to 5. It causes some issues that this commit attemps to fix: 1. Fail due to webpack resolving of Ace. Third-party dependency (code editor) Ace uses legacy `file-loader` for webpack resolving. It's not supported in webpack 5. So change it with manual imports. Refs: ajaxorg/ace-builds#211, ajaxorg/ace-builds#221. 2. Wehpack drops polyfilling node core modules (`path`, `fs`, etc.). Webpack does not polyfill those modules by default anymore. This is good because they did not need browser polyfilling as they are used in desktop version only and resolved already by Electron. To resolve errors (using webpack recommendations): - Add typeof check around `process` variable. - Tell webpack explicitly to ignore used node modules. 3. Fail due to legacy dependency of vue-cli-plugin-electron-builder. This plugin is used for electron builds and development. It still uses webpack 4 that leads to failed builds. Downgrading `ts-loader` to latest version which has support for `loader-utils` solves the problem (TypeStrong/ts-loader#1288). Related issue: nklayman/vue-cli-plugin-electron-builder#1625 4. Compilation fails due to webpack loading of `fsevents` on macOS. This happens only when running `vue-cli-service test:unit` command (used in integration tests and unit tests). Other builds work fine. Refs: yan-foto/electron-reload#71, nklayman/vue-cli-plugin-electron-builder#712, nklayman/vue-cli-plugin-electron-builder#1333
Remove usage of loader-utils:
#1286 (comment)