Building with Webpack causes spurious warnings

[avindra]

It is being caused by this line:

https://github.com/epoberezkin/ajv/blob/3.5.0/lib/compile/index.js#L10

Is there a cleaner way to manage this dependency? Is peerDependencies built for this?

Error stack below:

./~/ajv/lib/compile/index.js
Module not found: Error: Cannot resolve module 'js-beautify' in /app/myapp/node_modules/ajv/lib/compile
resolve module js-beautify in /app/myapp/node_modules/ajv/lib/compile
  looking for modules in /app/myapp/node_modules
    /app/myapp/node_modules/js-beautify doesn't exist (module as directory)
    resolve 'file' js-beautify in /app/myapp/node_modules
      resolve file
        /app/myapp/node_modules/js-beautify doesn't exist
        /app/myapp/node_modules/js-beautify.webpack.js doesn't exist
        /app/myapp/node_modules/js-beautify.web.js doesn't exist
        /app/myapp/node_modules/js-beautify.js doesn't exist
        /app/myapp/node_modules/js-beautify.json doesn't exist
  looking for modules in /app/myapp/public/js
    /app/myapp/public/js/js-beautify doesn't exist (module as directory)
    resolve 'file' js-beautify in /app/myapp/public/js
      resolve file
        /app/myapp/public/js/js-beautify doesn't exist
        /app/myapp/public/js/js-beautify.webpack.js doesn't exist
        /app/myapp/public/js/js-beautify.web.js doesn't exist
        /app/myapp/public/js/js-beautify.js doesn't exist
        /app/myapp/public/js/js-beautify.json doesn't exist
  looking for modules in /app/myapp/public/css
    /app/myapp/public/css/js-beautify doesn't exist (module as directory)
    resolve 'file' js-beautify in /app/myapp/public/css
      resolve file
        /app/myapp/public/css/js-beautify doesn't exist
        /app/myapp/public/css/js-beautify.webpack.js doesn't exist
        /app/myapp/public/css/js-beautify.web.js doesn't exist
        /app/myapp/public/css/js-beautify.js doesn't exist
        /app/myapp/public/css/js-beautify.json doesn't exist
[/app/myapp/node_modules/js-beautify]
[/app/myapp/node_modules/js-beautify]
[/app/myapp/node_modules/js-beautify.webpack.js]
[/app/myapp/node_modules/js-beautify.web.js]
[/app/myapp/node_modules/js-beautify.js]
[/app/myapp/node_modules/js-beautify.json]
[/app/myapp/public/js/js-beautify]
[/app/myapp/public/js/js-beautify]
[/app/myapp/public/js/js-beautify.webpack.js]
[/app/myapp/public/js/js-beautify.web.js]
[/app/myapp/public/js/js-beautify.js]
[/app/myapp/public/js/js-beautify.json]
[/app/myapp/public/css/js-beautify]
[/app/myapp/public/css/js-beautify]
[/app/myapp/public/css/js-beautify.webpack.js]
[/app/myapp/public/css/js-beautify.web.js]
[/app/myapp/public/css/js-beautify.js]
[/app/myapp/public/css/js-beautify.json]
 @ ./~/ajv/lib/compile/index.js 8:42-69

[epoberezkin]

If you are building with browserify it doesn't resolve this dependency at build-time (because there is an expression) and at a run-time it quietly fails if js-beautify is not available (it can be provided either as another bundle or included in ajv bundle by adding browserify CLI option). The reason for not including js-beautify in the bundle by default is the bundle size. It's unlikely one would need beautifying generated code in the browser, it's a debugging feature.

It seems that webpack tries to include modules even if their names are expressions. It's interesting what would it do if it encounters require(moduleName)?

You can of course resolve this issue by installing js-beautify so that webpack finds it. But you will also have to add nodent and regenerator that are required in a similar manner (they are used for asynchronous validation but one would never need both). So you'll end up with a large bundle full of things you don't need - 659Kb minified, while ajv itself is 109Kb (and I am thinking how to reduce it).

I am happy to modify the code in some way so that webpack can understand that these dependencies are optional and have to be resolved at run-time. I've searched but I don't see any elegant way to achieve it while still being compatible with node and browserify.

So until we find such a way, the workarounds are to use:

• the UMD bundle supplied with the npm package (in dist folder)
• the same bundle from cdnjs
• browserify. It seems that all webpack features (and more) can be implemented with browserify and existing transforms/utilities.

Any other ideas?

[epoberezkin]

By the way, does it fail to build or is it just a warning? If the latter, there should be a way to suppress warnings I hope.

[avindra]

Hi @epoberezkin : Thanks for the response.

How about moving the require statement into the opts.beautify check? I'm not sure if that would fix the issue (it wouldn't if Webpack is indeed resolving require statements statically. I can do a local test in a bit.

To answer your question, the build still passes, and is just a warning, but it pollutes the console with the aforementioned stack trace. Will report back in a bit.

[avindra]

Moving the require into self.opts.beautify doesn't fix it, so it looks like webpack is doing things statically. Hm.

[epoberezkin]

If they are just warnings you can either find some option in webpack to suppress the warning or you can webpack ... > /dev/null

[avindra]

Definitely don't want to go the route of hiding all warnings, as that will contain useful information for other modules. I'll try to find another way around this when I can.

[idchlife]

Any luck using this for browser via webpack?

[epoberezkin]

What is possible with webpack that is not possible with browserify?

[strax]

I managed to suppress errors with the following plugin added to Webpack configuration:

new IgnorePlugin(/regenerator|nodent|js\-beautify/, /ajv/)

[avindra]

@epoberezkin : AFAIK, browserify does not support code splitting, hot reloading or incremental builds. The latter two features completely change the game in terms of how productive you can be while writing javascript...

@strax : thanks for the tip, will give it a shot

[epoberezkin]

@avindra: it seems like it does, with additional tools: https://gist.github.com/substack/68f8d502be42d5cd4942

[epoberezkin]

@strax thanks!

[jsrraman]

@strax, new IgnorePlugin(/regenerator|nodent|js-beautify/, /ajv/) worked for me. Thanks

[epoberezkin]

Thanks. Probably worth making a note in readme in Using in browser.

[loris]

Hi, just saw that the issue has been closed. I might have missed it but latest release still generate the webpack errors. I suggest to keep it open until the warnings are removed (the IgnorePlugin trick is just a temporary workaround)

[epoberezkin]

I don't think it is possible to resolve in any other way. Webpack doesn't support dynamic imports. Optional dependencies need to be dynamic.
Why is it not an acceptable solution?

[seeden]

It is not acceptable solution because:
When you will create a library and anybody use it. He will see these very ugly messages during the build and almost everybody will tell you that your library is probably broken.

[epoberezkin]

It doesn't log warnings with IgnorePlugin, see above. Why using it is not an acceptable solution? If you know a better solution than to use IgnorePlugin, we can post it here. To me it seems the webpack's limitation that it doesn't support dynamic dependencies. If it turns out it does and there is a way to change code so it is still compatible with browserify and nodejs, we can change it.

[avindra]

I believe the issue here is that the JavaScript community does not have a standard for loading modules dynamically.

Webpack 2 will support System.import. I don't know what the spec is named, but I'll definitely be testing it when it releases.

[seeden]

@epoberezkin I am not talking about your library. But for example my library which is using your ajv library. I need to inform all my users about this problem because it looks like a bug in my library. I do not want to complain but you know it is ugly

[epoberezkin]

It will be resolved by #382 and #383

[epoberezkin]

Resolved in 5.0.1-beta.0
To use: npm install ajv@^5.0.1-beta

[epoberezkin]

5.0.1-beta.3 should resolve it, finally

[Oduig]

Hi there. I tried @strax's solution, but I'm still getting the three warnings. I ask because I am using request, which uses har-validator which uses ajv. It will take a while before the change propagates to request.

What is the magic combination of words to ignore AJV webpack warnings without generating other errors?

I apologize if this is not the right place, but I figure someone here might know the answer. Full question and fiddle on StackOverflow.

[epoberezkin]

I assume you mean #117 (comment)

I ask because I am using request, which uses har-validator which uses ajv. It will take a while before the change propagates to request.

As soon as it is changed in har-validator, request will use new version, there is nothing more to propagate.

I expect 2-3 weeks at most. Warnings aren't critical as long as it all works. You can also lock request to 2.79.0 if it's a problem.

[Oduig]

@epoberezkin Downgrading works for me. Thanks!

[d-winter]

Hey, does anybody has an idea why those warnings break my build?
When I use google-cloud, which uses google-auto-auth which uses request, this crashes my webpack build:

/Users/me/Development/MyProject/.webpack/handlers.js:243492
	__webpack_require__(940) = function(ids, factory) {

this is my webpack.config.js

var webpack = require('webpack');
module.exports = {
  entry: './handlers.js',
  target: 'node',
  devtool: 'source-map',
  module: {
    loaders: [
      {
        test: /\.js$/,
        loaders: ['babel'],
        include: __dirname,
        exclude: /node_modules/,
      },
      { test: /\.json$/, loader: 'json-loader' },
    ],
    plugins: [
      new webpack.IgnorePlugin(/regenerator|nodent|js\-beautify/, /ajv/),
    ],
  },
};

I am using serverless webpack.
Is there any way to find out why this happens? Sorry, but I am not very familiar with webpack. Any help would be awesome.

[davidecarpini]

import nodeExternals worked for me, i added this rows to my server.webpack.config:
`
import path from 'path';
++++import nodeExternals from 'webpack-node-externals';

const CONTEXT = path.join( __dirname, "../.." ),
INPUT_SERVER_DIR = path.join( CONTEXT, "server" ),
OUTPUT_SERVER_DIR = path.join( CONTEXT, "dist/server" );

export default [
{
name: 'server',
target: 'node',
context: INPUT_SERVER_DIR,
node: {
__dirname: false
},
entry: './server',
devtool : 'source-map',
output: {
path: OUTPUT_SERVER_DIR,
filename: "server.js"
},
module: {
rules: [
{
test: /.js$/,
exclude: /node_modules/,
loader: "babel-loader"
}
]
},
resolve: {
extensions: ['.js']
},
+++externals : [ nodeExternals() ]
}
];
`