Module build failed: Error: Final loader didn't return a Buffer or String #372
Comments
|
I have the same issue. Downgrading Typescript from 2.2.0 to 2.1.5 and awesome-typescript-loader to 3.0.0-beta.18 apparently wasn't enough for a temporary fix. |
|
I am having the same issue. I extracted the problematic module into a seperate project, but was unable to reproduce the error again. Anyone have any suggestions on what else I can do to narrow down what exactly is going wrong here? |
|
i think it's releated to this bug #320 |
|
I've upgraded to 3.0.4, and even deleted |
|
seems to be not fixed ... |
|
@s-panferov please reopen this issue.if you want any information are details please put up comments here.. |
|
@jagadeesh1492 @Shammah very interesting. Please create a repro case, because I have no idea how to reproduce this. |
|
This happens in my co-worker's machine but not mine. |
|
I'm trying to create a minimal test case by piece-wise removing functionality from our web app. I'm having some difficulty though, as it's somehow fixed out of the blue a lot of times. This is going to take some time. |
|
https://github.com/Shammah/awesome-typescript-loader-error.git I've tried to remove as much as possible from my test-case without "fixing" the error. You can checkout the repository and immediately run It seems to be related to the Http backend I use for testing purposes. If I remove it, it seems to work. |
|
@Shammah thanks, I'll check. |
|
Also experiencing the same thing. ATL 3.0.7. |
|
I had the same issue ("Final loader didn't return a Buffer or String") under #338. May be it reproduces not only on older versions of node, but it can depend on version of typescript? |
|
I had the same issue and nailed it down to be a watchpack problem. webpack/webpack#4341 |
|
Only works with ATL V2.2.4 and Typescript 2.1.1/2.0.10 |
|
Hello all. In one of our projects we're having this issue as well, same stacktrace from How would you go fixing the issue, if webpack has not released an upgrade yet? Just explicitly including watchpack 1.3.1 as a dependency in our project? TA |
|
In tsconfig.json, I configured the following: Then I am able use ATL 3.2.1 and Typescript 2.2.1 |
|
had a similar issue , finally what did the trick was
|
|
In the project I'm currently working on, had this same problem. Of the ATLoptions listed above, the only one required to fix the issue was "useTranspileModule". Based on what I'm seeing, this flag triggers the 'fast emit', which makes the TypeScript compiler output the 'transpiled' code instead of the 'compiled' code, which I take to mean it's just converted from TS straight to JS without all of the type-checking and re-factoring that makes TS awesome. At that point, might as well be writing in CoffeeScript or the like. Am I correct in my analysis of what "useTranspileModule" is doing? If so, what would the appropriate steps be to try and narrow down why 'compile' is unsuccessful but 'transpile' is just fine? |
|
I had the same issue and, after stepping through the code, saw that it was caused by the cache being stale. I had changed one of the ATL options and that should invalidate the cache, but I just saw it returning |
|
I'm refactoring typescript application to migrate from using internal modules to external modules and also got this error. In my case i had Removing "awesome-typescript-loader": "3.1.3" HTH |
|
@kcsahoo Thank you! |
|
this issue is connected with filename letter-case errors on case-insensitive file systems. need to find some workaround |
|
The issue happens in Windows when you have mixed casings in imports: For example: You will see "There are multiple modules with names that only differ in casing." warning probably at the same time. |
|
Just to confirm, I found that if I run the same task using console (cmd, git-bash) I am getting the error. If I run the same task using WebStorm - no error occurs at all. |
|
Maybe, this approach can helps? |
|
I faced the same issue, cleaning .awcache folder helped me. |
|
Happens to me when I try to import a JS file with |
|
@Hotzilla you're right. Thanks |
|
I had this error with a case error in import: running wepback from CLi reported the broken file |
|
@MadaraUchiha - that was the issue for me. Thanks so much! (Been banging my head against the keyboard for the past couple hours...) |
|
Just had this one. I just killed my hot update 'npm run dev' and restarted and issue disappeared. Filenames are sometimes cached causing me issues. This also causes me an issue when I use Swagger to generate a new API directory deleting the old one first. Hot update gets very confused and I have to kill 'npm run dev' |
|
Got this error after updating typescript from 2.8.x to 2.9.x. I'm using dotnet with hot module replacement (react-hot-loader) and I'm getting the error when the app hot reloads. Any one else has this issue? |
|
Also got this on a fresh webpack-dev-server setup. Compiling straight with webpack (same config) works but webpack-dev-server fails. const path = require('path');
module.exports = {
entry: './src/index.ts',
output: {
filename: 'bundle.js',
},
resolve: {
extensions: ['.ts', '.tsx', '.js', '.jsx'],
},
module: {
rules: [
{test: /\.(t|j)sx?$/, use: {loader: 'awesome-typescript-loader'}},
{enforce: 'pre', test: /\.js$/, loader: 'source-map-loader'},
],
},
devtool: 'source-map',
devServer: {
contentBase: path.join(__dirname, 'examples'),
port: 9000,
hot: true,
},
};I get a slightly different error if I remove |
|
I'm also getting this issue. Note that it should possibly be an upstream typescript bug, and the same issue as TypeStrong/ts-loader#568. I'm getting reproduction on my npmsupport branch, and was also getting a reproduction of TypeStrong/ts-loader#568 when using ts-loader. |
|
Tested it |
|
I am also suffering from the same problem. |
|
Still having this problem Error is being produced by import Superagent from "superagent"
Superagent.get("/kappa") |
and others
when i update the package to newer version i got this error
The text was updated successfully, but these errors were encountered: