Importing UMD built module using webpack leads to Critical Dependency errors
Asked Answered
E

1

6

I am trying to build a simple file that depends on a library built with UMD exports.

// main.ts
import { parseTree } from 'jsonc-parser';

const tree = parseTree('{ "name: "test" }');

console.log(tree);

It compiles fine, however webpack spits out dependency errors:

Hash: 85004e3e1bd3582666f5 Version: webpack 2.3.2 Time: 959ms Asset Size Chunks Chunk Names dist/bundle.js 61.8 kB 0 [emitted] main build/main.d.ts 0 bytes [emitted] [0] ./~/jsonc-parser/lib/main.js 40.1 kB {0} [built] [1] ./~/jsonc-parser/lib 160 bytes {0} [built] [2] ./~/path-browserify/index.js 6.18 kB {0} [built] [3] ./~/process/browser.js 5.3 kB {0} [built] [4] ./src/main.ts 200 bytes {0} [built] [5] ./~/vscode-nls/lib 160 bytes {0} [optional] [built] [6] ./~/vscode-nls/lib/main.js 5.46 kB {0} [built]

WARNING in ./~/jsonc-parser/lib/main.js 3:24-31 Critical dependency: require function is used in a way in which dependencies cannot be statically extracted

WARNING in ./~/vscode-nls/lib/main.js 118:23-44 Critical dependency: the request of a dependency is an expression

ERROR in ./~/vscode-nls/lib/main.js Module not found: Error: Can't resolve 'fs' in '.../webpack-typescript-umd/node_modules/vscode-nls/lib' @ ./~/vscode-nls/lib/main.js 7:9-22 @ ./~/jsonc-parser/lib/main.js @ ./src/main.ts

// webpack.config.js
const path = require('path');

module.exports = {
    entry: './src/main.ts',
    output: {
        filename: 'dist/bundle.js'
    },
    resolve: {
        // Add `.ts` and `.tsx` as a resolvable extension.
        extensions: ['.ts', '.tsx', '.js'] // note if using webpack 1 you'd also need a '' in the array as well
    },
    module: {
        loaders: [ // loaders will work with webpack 1 or 2; but will be renamed "rules" in future
            // all files with a `.ts` or `.tsx` extension will be handled by `ts-loader`
            {
                test: /\.tsx?$/,
                loader: 'ts-loader',
                options: {
                    configFileName: path.resolve(__dirname, 'tsconfig.json')
                }
            },
        ]
    }
}

I want to keep my js transpiled files as commonjs but I want to bundle jsonc-parser as well without recompiling it as commonjs.

I've created a repo on github that show cases the error. Hopefully this can help you.

You can simply npm install && npm run dist to reproduce the error.

Earthling answered 2/4, 2017 at 21:24 Comment(1)
Did you check the following thread: #38393197Thymelaeaceous
I
4

I ran into the same issue and wanted to share two ways to workaround the problem:

If the consumed package consists of one single module, just like before the 1.0.1 version of the jsonc-parser, you can add the following to your webpack.config.js:

module: {
    rules: [
        // your rules come here. 
    ],
    noParse: /jsonc-parser|other-umd-packages/
},

If the consumed package consists of multiple files, one can use the umd-compat-loader as a workaround. Add the umd-compat-loader loader to your package.json and configure the following rule in the webpack.config.js:

module: {
    rules: [
        // other rules come here.
        {
            test: /node_modules[\\|/](jsonc-parser|other-umd-packages)/,
            use: { loader: 'umd-compat-loader' }
        }
    ]
},

Some hints on how to properly use the test, can be found here. Finally, but not least, the credit goes to the OP of the workaround.

Indebtedness answered 16/2, 2018 at 9:33 Comment(3)
When using the umd-compat-loader, will the warning go away. I'm having trouble with my test condition, and am looking for a confirmation that I've succeeded in resolving my problem WITHOUT having to test my lambda.Kordofanian
> will the warning go away. @TheClassic, yes. It should.Indebtedness
Note to anyone who unfortunately needs to deal with this: umd-compat-loader is not smart enough to handle all cases. In its source code you can see that it looks for a hardcoded string var v = factory(require, exports); and assumes certain structures that are not universal -- the wrapper could easily use other variables or swap things.Interviewer

© 2022 - 2024 — McMap. All rights reserved.