beta23 doesn’t start if config object includes loader configs because of schema

I’m submitting a bug report

Webpack version:
2.1.0-beta.23

Please tell us about your environment:
Windows 10

Current behavior:

Invalid configuration object. Webpack has been initialised using a configuration object that does not match the API schema.
  - configuration has an unknown property 'htmlLoader'. These properties are valid:
    object { amd?, bail?, cache?, context?, devServer?, devtool?, entry, externals?, loader?, module?, name?, dependencies?, node?, output?, plugins?, profile?, recordsInputPath?, recordsOutputPath?, recordsPath?, resolve?, resolveLoader?, stats?, target?, watch?, watchOptions? }

Expected/desired behavior:
Schema should handle loader configurations, maybe?

Author: Fantashit

11 thoughts on “beta23 doesn’t start if config object includes loader configs because of schema

  1. @princemaple Yes, we just dropped this today, and I’ve been working furiously on a blogpost, and guide.

    Easiest migration steps for custom loader properties in config.

    plugins: [
      new webpack.LoaderOptionsPlugin({
        options: {
          htmlLoader: {
           whateverProp: true
          }
        }
      })
    ]
    
  2. That’s a shame you introduced this breaking change with no easy way to handle it.
    Having to use a plugin offers a really poor DX as it require more boilerplate. Webpack beginner (and even people confortable with) will be really frustrated with this.
    The real problem is that query does not accept anything than json. And since we are in a js file, it’s really awkard and frustrating. That’s why a lot of loaders started to use this pattern (use an object in exports).

    I think your best shot here is to accept real JS in loader query options. Currently if you pass JS (a function or a regex), you do not get any warnings. Your stuff magically disappear! (Unless you changed this behavior?)

    We need to do something and saying to people to use a plugin in addition to the loader seriously sucks. Like a lot.

    Is there any real reason query object only accept json? I guess it’s a legacy thing due to the string limitation, but I think it’s seriously time to reconsider this.

  3. @MoOx I hear you are a bit upset about this breaking change. Let me explain it.

    The real problem was that loader query doesn’t accept any object but only JSON. But some loaders needed plugins. This resulted in a workaround for loader. They took options from webpack configuration. I didn’t really like it, because this means there are two ways of passing options to a loader. But as there was no other way it was fine for me.

    beta.23 now adds support for any object as loader query. This means you can now pass your loader plugins via the options/query parameter to the loader. With most loaders this will work out of the box as they merged query object with options from configuration. But technically this could require a change in the loader. Because of this the “old” of passing options to the loader is still possible.

    beta.23 also adds a schema validation to the configuration. For this we also disallow custom properties in the configuration. Elsewise you won’t get a hint for typos (i. e. modul instead of module, it would be a custom property). That’s because any extra property you want to push to the loader need to be provided with the LoadersOptionsPlugin. On long term they should move into the loader options/query object.

    I try to document this change in the webpack 1 migration guide.

    We not trying to break your stuff, just trying to make it more clear and easy. But this requires some breaking changes…

  4. I understand why it was how it was.

    beta.23 now adds support for any object as loader query.

    Ok this makes me un-upset. I am not used to see release notes for webpack releases so I missed that.

    On long term they should move into the loader options/query object.

    Totally agree.

    Thanks for you explanations.

  5. I’d just like to point out to everyone that this is a beta version of the software and as a beta version it is still in heavy development, as such breaking changes should be expected. If this is going to cause problems for you in your development life cycle then you really should be using the previous stable version or if you absolutely have to have the latest then lock down your version to a previously known working implementation when issues like this arise.

  6. For people who came here looking for the solution of how to fix:

    resolve: {
        modulesDirectories: ['node_modules', 'bower_components', 'web_modules']
      }
    

    with the error of:

    Invalid configuration object. Webpack has been initialised using a configuration object that does not match the API schema.
     - configuration.resolve has an unknown property 'modulesDirectories'. These properties are valid:
       object { alias?, aliasFields?, cachePredicate?, descriptionFiles?, enforceExtension?, enforceModuleExtension?, extensions?, fileSystem?, mainFields?, mainFiles?, moduleExtensions?, modules?, plugins?, resolver?, symlinks?, unsafeCache? }
    

    Just change your webpack.config.js to:

        resolve: {
            modules: [
                'node_modules',
                'bower_components',
                'web_modules'
            ]
        }
    

    Also, this page is very helpful:

    https://github.com/webpack/webpack.js.org/blob/develop/content/how-to/upgrade-from-webpack-1.md#resolveroot-resolvefallback-resolvemodulesdirectories

Comments are closed.