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

webpack 4.0.0-alpha.0 feedback #6064

Closed
sokra opened this Issue Dec 4, 2017 · 45 comments

Comments

Projects
None yet
@sokra
Copy link
Member

sokra commented Dec 4, 2017

Big changes

  • Node.js 4 is no longer supported. Source Code was upgraded to a higher ecmascript version.
  • You have to choose (mode or --mode) between two modes now: production or development
    • production enables all kind of optimizations to generate optimized bundles
    • development enables comments and hint for development and enables the eval devtool
      • WIP: addition hints in development mode
    • production doesn't support watching, development is optimized for fast incremental rebuilds
    • production also enables module concatenating (Scope Hoisting)
    • You can configure this in detail with the flags in optimization.* (build your custom mode)
    • process.env.NODE_ENV are set to production or development (only in build code, not in config)
    • There is a hidden none mode which disables everything
  • import() returns always a namespace object. CommonJS modules are wrapped into the default export
    • This probably breaks your code, if you used to import CommonJs with import()
  • You no longer need to use these plugins:
    • NoEmitOnErrorsPlugin -> optimize.noEmitOnErrors (on by default in production mode)
    • ModuleConcatenationPlugin -> optimize.concatenateModules (on by default in production mode)
  • webpack now handles JSON different
    • You may need to add type: "javascript/auto" when transforming JSON via loader to JS
    • Just using JSON without loader should still work

Big features

  • webpack now supports these module types:
    • javascript/auto: (The default one in webpack 3) Javascript module with all module systems enabled: CommonJS, AMD, ESM
    • javascript/esm: EcmaScript modules, all other module system are not available
    • json: JSON data, JSON data is passed through unchanged and isn't parsed
    • webassembly/experimental: WebAssembly modules (currently experimental)
  • javascript/esm handles ESM more strict compared to javascript/auto:
    • Imported names need to exist on imported module
    • Non-ESM can only imported via default import, everything else (including namespace import) emit errors
  • In .mjs modules
    • javascript/esm is used
    • imports need to have an extension. No extensions are tried.
  • sideEffects: false is now supported in package.json
  • Instead of a JSONP function a JSONP array is used -> async support
    • WIP: There is no way to move runtime to another chunk yet
  • webpackInclude and webpackExclude are supported by the magic comment for import(). They allow to filter files when using a dynamic expression.
  • Resolving can now be configured with module.rules[].resolve. It's merged with the global configuration.
  • Sone Plugin options are now validated
    • WIP: Better output, no process exit, stack trace, more plugins
  • Multiple performance improvements, especially for faster incremental rebuilds

Features

  • Plugins added via CLI are prepended to take priority over config plugins
  • Module type is automatically choosen for mjs, json and wasm extensions. Other extensions need to be configured via module.rules[].type
  • added loaderContext.rootContext which points to the context options. Loaders may use it to make stuff relative to the application root.
  • Error for chunk loading now includes more information and two new properties type and request.
  • Incorrect options.dependencies configurations now throw error
  • webpacks AST can be passed directly from loader to webpack to avoid extra parsing
  • When using more than 25 exports mangled export names are shorter.
  • webpack now looks for the .wasm, .mjs, .js and .json extensions in this order
  • Sizes are now shown in kiB instead of kB in Stats
  • A resource query is supported in context
  • output.pathinfo is now on by default in develoment mode
  • in-memory caching is now off by default in production
  • script tags are no longer text/javascript and async as this are the default values (saves a few bytes)

Bugfixes

  • Generated comments no longer break on */
  • webpack no longer modifies the passed options object
  • Compiler "watch-run" hook now has the Compiler as first parameter
  • add chunkCallbackName to the schema to allow configurating WebWorker template

Removed features

  • removed module.loaders
  • removed loaderContext.options
  • removed Compilation.notCacheable flag
  • removed NoErrorsPlugin
  • removed Dependency.isEqualResource
  • removed NewWatchingPlugin

Breaking changes for plugins

  • new plugin system
    • plugin method is backward-compatible
    • Plugins should use Compiler.hooks.xxx.tap(<plugin name>, fn) now
  • New major version of enhanced-resolve
  • Templates for chunks may now generate multiple assets
  • Chunk.chunks/parents/blocks are no longer Arrays. A Set is used internally and there are methods to access it.
  • Parser.scope.renames and Parser.scope.definitions are no longer Objects/Arrays, but Map/Sets.
  • Parser uses StackedSetMap (LevelDB-like datastructure) instead of Arrays
  • Compiler.options is no longer set while applying plugins
  • Harmony Dependencies has changed because of refactoring
  • Dependency.getReference() may now return a weak property. Dependency.weak is now used by the Dependency base class and returned in the base impl of getReference()
  • Constructor arguments changed for all Modules
  • Merged options into options object for ContextModule and resolveDependencies
  • Changed and renamed dependencies for `import()
  • Moved Compiler.resolvers into Compiler.resolverFactory accessible with plugins
  • Dependency.isEqualResource has been replaced with Dependency.getResourceIdentifier

Incompatible plugins

Please comment

Incompatible loaders

  • file-loader -> Workaround A
  • vue-loader -> Workaround A
  • ejs-loader -> Workaround A
  • eslint-loader -> Workaround A
  • postcss-loader

Please comment

Broken features

Please comment


Workarounds:

Workround A

For loaders not migrated away from using this.options:

new LoaderOptionsPlugin({
  options: {
    context: process.cwd() // or the same value as `context`
  }
})

Don't expect this alpha release to be super stable yet...


Please comment if you find additional changes not in the changelog

@TheLarkInn

This comment has been minimized.

Copy link
Member

TheLarkInn commented Dec 4, 2017

cc @skipjack I know we had a separate issue for docs, but wanted to ping you on this also.

@TheLarkInn

This comment has been minimized.

Copy link
Member

TheLarkInn commented Dec 4, 2017

Also marking as a Contribution opportunity. Testing and reporting feedback is a huge contribution opportunity, and help would be greatly appreciated.

@dangodev

This comment has been minimized.

Copy link

dangodev commented Dec 4, 2017

I re-ran some existing 3.x builds with the alpha just now. No successful builds, due to loader errors (and a webpacker error, in case you’re curious). Here are some errors from the output. I’d be happy to open issues on these loaders if needed.

ejs-loader

ERROR in   Error: Child compilation failed:
  Module build failed: TypeError: Cannot read property 'ejsLoader' of undefined
  - TypeError: Cannot read property 'ejsLoader' of undefined
  - compiler.js:76
    [lineage]/[html-webpack-plugin]/lib/compiler.js:76:16
  - Compiler.js:412 compile
    [lineage]/[webpack]/lib/Compiler.js:412:11
  - Compiler.js:621 hooks.afterCompile.callAsync.err
    [lineage]/[webpack]/lib/Compiler.js:621:14
  - Compiler.js:618 compilation.seal.err
    [lineage]/[webpack]/lib/Compiler.js:618:30
  - Compilation.js:842 hooks.optimizeAssets.callAsync.err
    [lineage]/[webpack]/lib/Compilation.js:842:35
  - Compilation.js:833 hooks.optimizeChunkAssets.callAsync.err
    [lineage]/[webpack]/lib/Compilation.js:833:32
  - index.js:244 AsyncSeriesHook._x
    [lineage]/[uglifyjs-webpack-plugin]/dist/index.js:244:6
  - Compilation.js:828 hooks.additionalAssets.callAsync.err
    [lineage]/[webpack]/lib/Compilation.js:828:36
  - Compilation.js:824 hooks.optimizeTree.callAsync.err
    [lineage]/[webpack]/lib/Compilation.js:824:32
  - Compilation.js:767 Compilation.seal
    [lineage]/[webpack]/lib/Compilation.js:767:27
  - Compiler.js:615 hooks.make.callAsync.err
    [lineage]/[webpack]/lib/Compiler.js:615:17
  - Compilation.js:668 _addModuleChain
    [lineage]/[webpack]/lib/Compilation.js:668:11
  - Compilation.js:605 processModuleDependencies.err
    [lineage]/[webpack]/lib/Compilation.js:605:14
  - next_tick.js:131 _combinedTickCallback
    internal/process/next_tick.js:131:7
  - next_tick.js:180 process._tickCallback
    internal/process/next_tick.js:180:9

file-loader

ERROR in ./assets/images/icons/search.svg
Module build failed: TypeError: Cannot read property 'context' of undefined
    at Object.loader (/Users/drew/Sites/my-site/node_modules/file-loader/dist/index.js:34:49)
 @ ./styles.sass 6:40863-40906

vue-loader

ERROR in ./components/Quote.vue
Module build failed: TypeError: Cannot read property 'vue' of undefined
    at Object.module.exports (/Users/drew/Sites/my-site/node_modules/vue-loader/lib/loader.js:57:18)
 @ ./printing.js 15:13-42

…And here’s an error from running webpack from rails/webpacker:

TypeError: dep.getResourceIdentifier is not a function
    at addDependency (/Users/drew/Sites/my-site/node_modules/webpack/lib/Compilation.js:322:30)
    at iterationOfArrayCallback (/Users/drew/Sites/my-site/node_modules/webpack/lib/Compilation.js:52:3)
    at addDependenciesBlock (/Users/drew/Sites/my-site/node_modules/webpack/lib/Compilation.js:339:5)
    at Compilation.processModuleDependencies (/Users/drew/Sites/my-site/node_modules/webpack/lib/Compilation.js:350:4)
    at _this.buildModule.err (/Users/drew/Sites/my-site/node_modules/webpack/lib/Compilation.js:509:14)
    at callbackList.forEach.cb (/Users/drew/Sites/my-site/node_modules/webpack/lib/Compilation.js:286:31)
    at Array.forEach (<anonymous>)
    at callback (/Users/drew/Sites/my-site/node_modules/webpack/lib/Compilation.js:286:17)
    at module.build (/Users/drew/Sites/my-site/node_modules/webpack/lib/Compilation.js:314:11)
    at doBuild (/Users/drew/Sites/my-site/node_modules/webpack/lib/NormalModule.js:326:11)
    at runLoaders (/Users/drew/Sites/my-site/node_modules/webpack/lib/NormalModule.js:230:11)
    at /Users/drew/Sites/my-site/node_modules/loader-runner/lib/LoaderRunner.js:370:3
    at iterateNormalLoaders (/Users/drew/Sites/my-site/node_modules/loader-runner/lib/LoaderRunner.js:211:10)
    at Array.<anonymous> (/Users/drew/Sites/my-site/node_modules/loader-runner/lib/LoaderRunner.js:202:4)
    at Storage.finished (/Users/drew/Sites/my-site/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:43:16)
    at provider (/Users/drew/Sites/my-site/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:79:9)
    at /Users/drew/Sites/my-site/node_modules/graceful-fs/graceful-fs.js:78:16
    at FSReqWrap.readFileAfterClose [as oncomplete] (fs.js:528:3)
@TheLarkInn

This comment has been minimized.

Copy link
Member

TheLarkInn commented Dec 4, 2017

file-loader (use of context, probably needs to be moved to rootContext). @d3viant0ne I'm going to tackle this. Let's create issue.

vue-loader is also a context issue. @LinusBorg - This will be a breaking change, I can help if needed.

The last error I'm not sure which one that is.

@TheLarkInn

This comment has been minimized.

Copy link
Member

TheLarkInn commented Dec 4, 2017

Thanks @dangodev - The last one is html-webpack-plugin and I've attached an issue already. I'll link up to description. If you'd like to save @d3viant0ne the effort we'd be happy to take a file-loader issue!

@sdoomz

This comment has been minimized.

Copy link

sdoomz commented Dec 4, 2017

Trying to build 3.10 project with webpack 4.0.0-alpha.0 - it fails after few second.
Node 7.8.0, 8.9.0.

eslint-loader

Module build failed: TypeError: Cannot read property 'eslint' of undefined
    at Object.module.exports (/Users/svyatoslav/Dev/wix-vod/wix-vod/node_modules/eslint-loader/index.js:148:18)
webpack: Failed to compile.

seems like it's related to removed loaderContext.options

@TheLarkInn

This comment has been minimized.

Copy link
Member

TheLarkInn commented Dec 4, 2017

Yes!

@michael-ciniawsky

This comment has been minimized.

Copy link
Member

michael-ciniawsky commented Dec 5, 2017

package.json

{ 
  name: 'package',
  version: '1.0.0'
  main: 'path/to/cjs.js',
  module: {
    type: 'pure', // <= instead of sideEffects
    path: 'path/to/esm.js' // or 'url' || 'src' || 'file'
  }
}

:)

@billyjanitsch

This comment has been minimized.

Copy link
Member

billyjanitsch commented Dec 5, 2017

Thanks for the opportunity to give feedback and congratulations on the alpha release.

How does mode interface with env as provided by function configs? Are function configs still the recommended way to handle customizing the config depending on the mode?

I ask because while it's great that the dev/prod distinction is being made first-class, I'm sure that users will still want to configure webpack's behavior as a function of the environment, and it would be great if webpack suggested a standard way of doing this.

@sdoomz

This comment has been minimized.

Copy link

sdoomz commented Dec 5, 2017

@TheLarkInn what is recommended to use instead of loaderContext.options this._compiler.options?

@swarajgiri

This comment has been minimized.

Copy link

swarajgiri commented Dec 5, 2017

@TheLarkInn
Building 3.10 project with webpack 4.0.0-alpha.0
Node - v8.9.1

offline-plugin: TypeError: compilation.fileDependencies.indexOf is not a function

if (compilation.fileDependencies.indexOf(runtimeTemplatePath) === -1 && !_this2.__tests.ignoreRuntime) {

TypeError: compilation.fileDependencies.indexOf is not a function
at Array. (/var/www/test4/dashboard/node_modules/offline-plugin/lib/index.js:292:42)
at _next (eval at compile (/var/www/test4/dashboard/node_modules/tapable/lib/Hook.js:21:10), :17:15)
at _handler (eval at compile (/var/www/test4/dashboard/node_modules/tapable/lib/Hook.js:21:10), :14:7)
at Array.compiler.plugin (/var/www/test4/dashboard/node_modules/webpack/lib/ProgressPlugin.js:191:5)
at _next (eval at compile (/var/www/test4/dashboard/node_modules/tapable/lib/Hook.js:21:10), :17:15)
at AsyncSeriesHook.eval [as callAsync] (eval at compile (/var/www/test4/dashboard/node_modules/tapable/lib/Hook.js:21:10), :19:6)
at AsyncSeriesHook.eval [as _callAsync] (eval at createCompileDelegate (/var/www/test4/dashboard/node_modules/tapable/lib/Hook.js:55:10), :5:16)
at Compiler.emitAssets (/var/www/test4/dashboard/node_modules/webpack/lib/Compiler.js:470:19)
at onCompiled (/var/www/test4/dashboard/node_modules/webpack/lib/Compiler.js:64:19)
at hooks.afterCompile.callAsync.err (/var/www/test4/dashboard/node_modules/webpack/lib/Compiler.js:621:14)
at _callback._x (eval at compile (/var/www/test4/dashboard/node_modules/tapable/lib/Hook.js:21:10), :8:6)
at AsyncSeriesHook.compiler.plugin [as _x] (/var/www/test4/dashboard/node_modules/webpack/lib/CachePlugin.js:71:5)
at AsyncSeriesHook.eval [as callAsync] (eval at compile (/var/www/test4/dashboard/node_modules/tapable/lib/Hook.js:21:10), :3:10)
at AsyncSeriesHook.eval [as _callAsync] (eval at createCompileDelegate (/var/www/test4/dashboard/node_modules/tapable/lib/Hook.js:55:10), :5:16)
at compilation.seal.err (/var/www/test4/dashboard/node_modules/webpack/lib/Compiler.js:618:30)
at AsyncSeriesHook.eval [as callAsync] (eval at compile (/var/www/test4/dashboard/node_modules/tapable/lib/Hook.js:21:10), :3:5)
at AsyncSeriesHook.eval [as _callAsync] (eval at createCompileDelegate (/var/www/test4/dashboard/node_modules/tapable/lib/Hook.js:55:10), :5:16)
at hooks.optimizeAssets.callAsync.err (/var/www/test4/dashboard/node_modules/webpack/lib/Compilation.js:842:35)
at _callback._x (eval at compile (/var/www/test4/dashboard/node_modules/tapable/lib/Hook.js:21:10), :8:6)
at AsyncSeriesHook.compilation.plugin [as _x] (/var/www/test4/dashboard/node_modules/webpack/lib/ProgressPlugin.js:186:6)
at AsyncSeriesHook.eval [as callAsync] (eval at compile (/var/www/test4/dashboard/node_modules/tapable/lib/Hook.js:21:10), :3:10)
at AsyncSeriesHook.eval [as _callAsync] (eval at createCompileDelegate (/var/www/test4/dashboard/node_modules/tapable/lib/Hook.js:55:10), :5:16)
at hooks.optimizeChunkAssets.callAsync.err (/var/www/test4/dashboard/node_modules/webpack/lib/Compilation.js:833:32)
at _callback._x (eval at compile (/var/www/test4/dashboard/node_modules/tapable/lib/Hook.js:21:10), :8:6)
at AsyncSeriesHook.compilation.plugin [as _x] (/var/www/test4/dashboard/node_modules/webpack/lib/ProgressPlugin.js:182:6)
at AsyncSeriesHook.eval [as callAsync] (eval at compile (/var/www/test4/dashboard/node_modules/tapable/lib/Hook.js:21:10), :3:10)
at AsyncSeriesHook.eval [as _callAsync] (eval at createCompileDelegate (/var/www/test4/dashboard/node_modules/tapable/lib/Hook.js:55:10), :5:16)
at hooks.additionalAssets.callAsync.err (/var/www/test4/dashboard/node_modules/webpack/lib/Compilation.js:828:36)
at _handler (eval at compile (/var/www/test4/dashboard/node_modules/tapable/lib/Hook.js:21:10), :11:8)
at Array.compilation.plugin.callback (/var/www/test4/dashboard/node_modules/webpack/lib/ProgressPlugin.js:178:6)

@AlexanderOMara

This comment has been minimized.

Copy link

AlexanderOMara commented Dec 5, 2017

  • In .mjs modules
    • imports need to have an extension. No extensions are tried.

This behavior does not match Node's current experimental ES module loader.

Here is a Gist to demonstrate that code that will run in Node (with --experimental-modules) fails to bundle in this alpha version of Webpack 4 (although I think Webpack 3 could be configured to bundle it).

On a side note, this could also make code more-difficult to transpile.

@vramana

This comment has been minimized.

Copy link

vramana commented Dec 5, 2017

@billyjanitsch devDependencies, peerDependencies, etc.,

@sokra

This comment has been minimized.

Copy link
Member

sokra commented Dec 5, 2017

@dangodev for the loader errors see new Workaround A in the issue.

for the webpacker issue: not sure yet, looks like a custom Dependency.


@billyjanitsch

The camel casing of sideEffects in package.json is odd, because, by convention, all other fields (including those added by other packages) use dash separation. Would you consider renaming the field to side-effects?

package.json fields use camelCasing: devDependencies peerDependencies publishConfig. Maybe these other packages did it wrong?


@billyjanitsch

Another general question: how does mode interface with env as provided by function configs? Are function configs still the recommended way to handle customizing the config depending on the mode?

Yep, either use a env function and set mode depending on passed env or use two configuration files.


@swarajgiri

offline-plugin: compilation.fileDependencies is now a Set. They need to change to has which is faster anyway.


@AlexanderOMara

This behavior does not match Node's current experimental ES module loader.

Yep, maybe I missunderstood something here. We can change this back easily.

Workaround:

module.rules: [ {
  test: /\.mjs$/,
  resolve: {
    extensions: [".wasm", ".mjs", ".js", ".json"]
  }
} ]
@sokra

This comment has been minimized.

Copy link
Member

sokra commented Dec 5, 2017

Thanks for being alpha testers... ❤️

@billyjanitsch

This comment has been minimized.

Copy link
Member

billyjanitsch commented Dec 5, 2017

@sokra

package.json fields use camelCasing

Sorry, mental lapse. You're absolutely right.

Yep, either use a env function and set mode depending on passed env or use two configuration files.

Cool! So how does this affect -d and -p flags -- do they now automatically set the mode (which would, if I'm understanding mode correctly, be equivalent to their current behavior)?

@sokra

This comment has been minimized.

Copy link
Member

sokra commented Dec 5, 2017

do they now automatically set the mode (which would, if I'm understanding mode correctly, be equivalent to their current behavior)?

yes

-d = --mode development --devtool cheap-module-eval-source-map
-p = --mode production --plugin uglifyjs-webpack-plugin

But this is subject to change as CLI will move into webpack/webpack-cli.

@kingdaro

This comment has been minimized.

Copy link
Contributor

kingdaro commented Dec 5, 2017

I assume you can still use the full --development and --production flags? Since I prefer that over the shorthands for readability.

@OlegLustenko

This comment has been minimized.

Copy link

OlegLustenko commented Dec 5, 2017

is it still required to set HotModuleReplacment in development build ?

I reached that error on rebuild
image

@michael-ciniawsky

This comment has been minimized.

Copy link
Member

michael-ciniawsky commented Dec 5, 2017

@filipesilva Open an issue in postcss-loader if you have any problems, I will address it there :)

@filipesilva

This comment has been minimized.

Copy link
Contributor

filipesilva commented Dec 5, 2017

@johnnyreilly

This comment has been minimized.

Copy link
Contributor

johnnyreilly commented Dec 5, 2017

@sokra - now that's a speedy response! Thanks!

I'm guessing that "MyLoggingPlugin" is just a string that you should use consistently in your plugin code wherever you use compiler.hooks.hookNameHere to identify your plugin?

Also, can you confirm that all compiler.plugin calls become compiler.hooks.hookNameHere? Seems likely!

@sokra

This comment has been minimized.

Copy link
Member

sokra commented Dec 5, 2017

Actually you can use any string as MyLoggingPlugin. It's use by the intercepting api of the plugin system. i. e. the string will be displayed by the ProgressPlugin in the console or used to label profiling information captured. So best use your plugin name. If your plugin is intended to be used multiple times, best also add a unique identifier.

@michael-ciniawsky

This comment has been minimized.

Copy link
Member

michael-ciniawsky commented Dec 5, 2017

postcss-loader@latest is 'fixed' (works) (false alert/user error)

@iamakulov

This comment has been minimized.

Copy link

iamakulov commented Dec 5, 2017

To learn what exact effect the mode flag has – see https://github.com/webpack/webpack/blob/next/lib/WebpackOptionsDefaulter.js (Ctrl+F for “.mode”).

(For everyone who was also curious)

@iamakulov

This comment has been minimized.

Copy link

iamakulov commented Dec 5, 2017

What surprised me though is that the UglifyJsPlugin is not enabled in the production mode by default.

My expectations were like “I write mode: 'production', specify entry, output, a couple of loaders, and it just works.” Without minification, the production mode feels half-baked or incomplete – I still have to add additional plugins to make it work.

Would it make sense to enable the UglifyJsPlugin in production? We’ll have to make the plugin disableable (for folks that use other minifiers), so probably it would make sense to add an optimization.minimize: true/false option that enables/disables it. Because this plugin has options, we could either allow passing them into optimization.minimize:

module.exports = {
  optimization: {
    minimize: {
      sourceMap: true,
    },
  },
};

or create a separate field for them (e.g. optimization.minimizeOptions).

@TheLarkInn

This comment has been minimized.

Copy link
Member

TheLarkInn commented Dec 5, 2017

@iamakulov Would you mind linking that one up into a separate issue. I have some specific thoughts about it after playing around a few times and believe it should be left out of the mode.

@iamakulov

This comment has been minimized.

Copy link

iamakulov commented Dec 5, 2017

@TheLarkInn Done! #6075

Interested to hear your thoughts :–)

@geovanisouza92

This comment has been minimized.

Copy link

geovanisouza92 commented Dec 7, 2017

I hope that this helps: I just updated to alpha version and my build for AWS Lambda worked all fine. Just some plugins and loaders emitted deprecation warnings.

My webpack.config.js:

const path = require('path')

const plugins = []

if (/build/.test(process.env.npm_lifecycle_event)) {
  const wba = require('webpack-bundle-analyzer')
  plugins.push(
    new wba.BundleAnalyzerPlugin({
      analyzerMode: 'static',
      openAnalyzer: false,
      reportFilename: 'report.html'
    })
  )
}

let devtool = undefined
if (/production/.test(process.env.npm_lifecycle_event)) {
  devtool = 'source-map'
}

module.exports = {
  entry: {
    chunk1: path.resolve(__dirname, 'src/chunk1.ts'),
    chunk2: path.resolve(__dirname, 'src/chunk2.ts'),
    chunk3: path.resolve(__dirname, 'src/chunk3.js'),
    chunk4: path.resolve(__dirname, 'src/chunk4.js')
  },
  output: {
    path: path.resolve(__dirname, 'build'),
    filename: '[name]/index.js',
    libraryTarget: 'commonjs2'
  },
  target: 'node',
  devtool,
  externals: {
    'aws-sdk': 'commonjs aws-sdk'
  },
  plugins,
  resolve: {
    extensions: ['.js', '.json', '.ts'],
    modules: ['node_modules', __dirname]
  },
  module: {
    rules: [
      {
        test: /\.ts$/,
        exclude: /node_modules/,
        use: ['babel-loader', 'awesome-typescript-loader']
      },
      {
        test: /\.js$/,
        exclude: /node_modules/,
        use: 'babel-loader'
      },
      {
        test: /\.raw\.js$/,
        use: path.resolve(__dirname, 'scripts/raw-js-loader.js')
      },
      {
        test: /\.raw\.css$/,
        use: path.resolve(__dirname, 'scripts/raw-css-loader.js')
      },
      {
        test: /\.xml$/,
        use: 'raw-loader'
      }
    ]
  }
}
@sokra

This comment has been minimized.

Copy link
Member

sokra commented Dec 8, 2017

Great to hear @geovanisouza92

@TheLarkInn

This comment has been minimized.

Copy link
Member

TheLarkInn commented Dec 8, 2017

@sokra doesn't the first tap arg also take an object so you could pass metadata into there?

@sokra

This comment has been minimized.

Copy link
Member

sokra commented Dec 8, 2017

Yep you can pass more options:

{
  name: "...", // required name
  before: "CommonsChunkPlugin", // inserted before this tap
  stage: -10 // taps are ordered by stage
}
@machineloop

This comment has been minimized.

Copy link

machineloop commented Dec 8, 2017

I'm getting the following when I bump up to v4 Alpha, what's the best way to figure out which plugin is breaking?

Running "webpack:build" (webpack) task
Warning: this.compiler.applyPluginsAsync is not a function Used --force, continuing.
(node:59256) DeprecationWarning: Tapable.plugin is deprecated. Use new API on `.hooks` instead
(node:59256) DeprecationWarning: Tapable.apply is deprecated. Call apply on the plugin directly instead
@phyllisstein

This comment has been minimized.

Copy link

phyllisstein commented Dec 9, 2017

Noticed something a bit odd with webpack-dev-middleware: the backwards-compatible plugin call is only backwards-compatible when the middleware is passed a single configuration object. When it's passed an array of configuration objects, I get the following error:

/Users/daniel/Repos/Ignota/ordo/node_modules/webpack/node_modules/tapable/lib/Tapable.js:63
		throw new Error(`Plugin could not be registered at '${name}'. Hook was not found.\n` +
		^

Error: Plugin could not be registered at 'watch-run'. Hook was not found.
BREAKING CHANGE: There need to exist a hook at 'this.hooks'. To create a compatiblity layer for this hook, hook into 'this._pluginCompat'.
    at MultiCompiler.plugin (/Users/daniel/Repos/Ignota/ordo/node_modules/webpack/node_modules/tapable/lib/Tapable.js:63:9)
    at MultiCompiler.deprecated [as plugin] (internal/util.js:52:15)
    at Shared (/Users/daniel/Repos/Ignota/ordo/node_modules/webpack-dev-middleware/lib/Shared.js:235:19)
    at module.exports (/Users/daniel/Repos/Ignota/ordo/node_modules/webpack-dev-middleware/middleware.js:22:15)
    at Object.<anonymous> (/Users/daniel/Repos/Ignota/ordo/packages/client/app.js:16:5)
    at Module._compile (module.js:641:30)
    at Object.Module._extensions..js (module.js:652:10)
    at Module.load (module.js:560:32)
    at tryModuleLoad (module.js:503:12)
    at Function.Module._load (module.js:495:3)

I gisted a snippet of my Webpack config, in case that's helpful: https://gist.github.com/phyllisstein/d58d9516ef3b360156969ddac441eb90. Would be grateful if anyone could suggest a workaround, the alpha was lots of fun up to this point. 😬

@simonjoom

This comment has been minimized.

Copy link

simonjoom commented Dec 10, 2017

I use webpack 4 (last commit) for my application working good after many test.
i use a rule for json with a personal loader (for routes)
type: "javascript/esm" is not working, (my requires are not resolved)
for me i have to use "javascript/auto" (parameters that i found in the source code)

Maybe you should to give more documentation about this "javascript/auto" "javascript/dynamic" and "javascript/esm"

 test: /\.json$/,
        type: "javascript/auto",
use: [
          {
            loader: 'babel-loader',
            options: babelConfig,
          },
          {
            loader: path.resolve(process.cwd(), './utils/routes-loaderPR.js'),
            options: {
              context: process.cwd(),
            }
          },
]
@TheLarkInn

This comment has been minimized.

Copy link
Member

TheLarkInn commented Dec 10, 2017

@simonjoom what if you just remove the .json rule all together etc.

bors bot added a commit to jser/jser.github.io that referenced this issue Dec 11, 2017

Merge #466
466: 2017-12-11 JS: Parcel、webpack 4.0.0α、Node.js Performance r=azu a=azu

- [📦 Parcel](https://parceljs.org/ "📦 Parcel")
- [🚀 Announcing Parcel: A blazing fast, zero configuration web application bundler 📦](https://hackernoon.com/announcing-parcel-a-blazing-fast-zero-configuration-web-application-bundler-feac43aac0f1)
- [🔌 Plugins](https://parceljs.org/plugins.html)
- Benchmark issue
  - [Publish benchmarks app · Issue #9 · parcel-bundler/parcel](parcel-bundler/parcel#9)
  - [Feature request: source map support · Issue #68 · parcel-bundler/parcel](parcel-bundler/parcel#68)
- [webpack 4.0.0-alpha.0 feedback · Issue #6064 · webpack/webpack](webpack/webpack#6064)
  - [Vote](https://webpack.js.org/vote/)
  - [Sean Thomas Larkin on Twitter: "Alright #JavaScript #webpack folks, I've created the voting item! If you _really_ want a Zero Configuration (aka your configs live in .pos… https://t.co/w5WE8T0I0J"](https://twitter.com/TheLarkInn/status/938928029044170752)
- [Node.js Performance 改善ガイド - from scratch](http://yosuke-furukawa.hatenablog.com/entry/2017/12/05/125517)
@kisenka

This comment has been minimized.

Copy link
Contributor

kisenka commented Dec 14, 2017

If somebody (like me) didn't understand how loader should gather options in webpack@4 here is an answer - use loader-utils#getOptions. Please add this info to workaround section for loader authors, it will save much time.

@sokra

This comment has been minimized.

Copy link
Member

sokra commented Dec 14, 2017

New alpha version: #6132

@sokra sokra closed this Dec 14, 2017

@webpack webpack locked and limited conversation to collaborators Dec 14, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.