webpack / enhanced-resolve

Offers an async require.resolve function. It's highly configurable.

webpack

Webpack is a module bundler. Its main purpose is to bundle JavaScript files for usage in a browser, yet it is also capable of transforming, bundling, or packaging just about any resource or asset.

Table of Contents

1. Install
2. Introduction
3. Concepts
4. Contributing
5. Support
6. Core Team
7. Sponsoring
8. Premium Partners
9. Other Backers and Sponsors
10. Gold Sponsors
11. Silver Sponsors
12. Bronze Sponsors
13. Backers
14. Special Thanks

Install

Install with npm:

npm install --save-dev webpack

Install with yarn:

yarn add webpack --dev

Introduction

Webpack is a bundler for modules. The main purpose is to bundle JavaScript files for usage in a browser, yet it is also capable of transforming, bundling, or packaging just about any resource or asset.

TL;DR

• Bundles ES Modules, CommonJS, and AMD modules (even combined).
• Can create a single bundle or multiple chunks that are asynchronously loaded at runtime (to reduce initial loading time).
• Dependencies are resolved during compilation, reducing the runtime size.
• Loaders can preprocess files while compiling, e.g. TypeScript to JavaScript, Handlebars strings to compiled functions, images to Base64, etc.
• Highly modular plugin system to do whatever else your application requires.

Get Started

Check out webpack's quick Get Started guide and the other guides.

Browser Compatibility

Webpack supports all browsers that are ES5-compliant (IE8 and below are not supported). Webpack also needs Promise for import() and require.ensure(). If you want to support older browsers, you will need to load a polyfill before using these expressions.

Concepts

Plugins

Webpack has a rich plugin interface. Most of the features within webpack itself use this plugin interface. This makes webpack very flexible.

Name	Status	Install Size	Description
mini-css-extract-plugin			Extracts CSS into separate files. It creates a CSS file per JS file which contains CSS.
compression-webpack-plugin			Prepares compressed versions of assets to serve them with Content-Encoding
html-webpack-plugin			Simplifies creation of HTML files (index.html) to serve your bundles
pug-plugin			Renders Pug files to HTML, extracts JS and CSS from sources specified directly in Pug.

Loaders

Webpack enables the use of loaders to preprocess files. This allows you to bundle any static resource way beyond JavaScript. You can easily write your own loaders using Node.js.

Loaders are activated by using loadername! prefixes in require() statements, or are automatically applied via regex from your webpack configuration.

Files

Name	Status	Install Size	Description
val-loader			Executes code as module and considers exports as JS code

JSON

Name	Status	Install Size	Description
			Loads and transpiles a CSON file

Transpiling

Name	Status	Install Size	Description
			Loads ES2015+ code and transpiles to ES5 using Babel
			Loads TypeScript like JavaScript
			Loads CoffeeScript like JavaScript

Templating

Name	Status	Install Size	Description
			Exports HTML as string, requires references to static resources
			Loads Pug templates and returns a function
			Compiles Pug to a function or HTML string, useful for use with Vue, React, Angular
			Compiles Markdown to HTML
			Loads and transforms a HTML file using PostHTML
			Compiles Handlebars to HTML

Styling

Name	Status	Install Size	Description
<style>			Add exports of a module as style to DOM
			Loads CSS file with resolved imports and returns CSS code
			Loads and compiles a LESS file
			Loads and compiles a Sass/SCSS file
			Loads and compiles a Stylus file
			Loads and transforms a CSS/SSS file using PostCSS

Frameworks

Name	Status	Install Size	Description
			Loads and compiles Vue Components
			Process HTML & CSS with preprocessor of choice and require() Web Components like first-class modules
			Loads and compiles Angular 2 Components
			Riot official webpack loader
			Official Svelte loader

Performance

Webpack uses async I/O and has multiple caching levels. This makes webpack fast and incredibly fast on incremental compilations.

Module Formats

Webpack supports ES2015+, CommonJS and AMD modules out of the box. It performs clever static analysis on the AST of your code. It even has an evaluation engine to evaluate simple expressions. This allows you to support most existing libraries out of the box.

Code Splitting

Webpack allows you to split your codebase into multiple chunks. Chunks are loaded asynchronously at runtime. This reduces the initial loading time.

Optimizations

Webpack can do many optimizations to reduce the output size of your JavaScript by deduplicating frequently used modules, minifying, and giving you full control of what is loaded initially and what is loaded at runtime through code splitting. It can also make your code chunks cache friendly by using hashes.

Contributing

We want contributing to webpack to be fun, enjoyable, and educational for anyone, and everyone. We have a vibrant ecosystem that spans beyond this single repo. We welcome you to check out any of the repositories in our organization or webpack-contrib organization which houses all of our loaders and plugins.

Contributions go far beyond pull requests and commits. Although we love giving you the opportunity to put your stamp on webpack, we also are thrilled to receive a variety of other contributions including:

• Documentation updates, enhancements, designs, or bugfixes
• Spelling or grammar fixes
• README.md corrections or redesigns
• Adding unit, or functional tests
• Triaging GitHub issues -- especially determining whether an issue still persists or is reproducible.
• Searching #webpack on twitter and helping someone else who needs help
• Teaching others how to contribute to one of the many webpack's repos!
• Blogging, speaking about, or creating tutorials about one of webpack's many features.
• Helping others in our webpack gitter channel.

To get started have a look at our documentation on contributing.

If you are worried or don't know where to start, you can always reach out to Sean Larkin (@TheLarkInn) on Twitter or simply submit an issue and a maintainer can help give you guidance!

We have also started a series on our Medium Publication called The Contributor's Guide to webpack. We welcome you to read it and post any questions or responses if you still need help.

Looking to speak about webpack? We'd love to review your talk abstract/CFP! You can email it to webpack [at] opencollective [dot] com and we can give pointers or tips!!!

Creating your own plugins and loaders

If you create a loader or plugin, we would <3 for you to open source it, and put it on npm. We follow the x-loader, x-webpack-plugin naming convention.

Support

We consider webpack to be a low-level tool used not only individually but also layered beneath other awesome tools. Because of its flexibility, webpack isn't always the easiest entry-level solution, however we do believe it is the most powerful. That said, we're always looking for ways to improve and simplify the tool without compromising functionality. If you have any ideas on ways to accomplish this, we're all ears!

If you're just getting started, take a look at our new docs and concepts page. This has a high level overview that is great for beginners!!

Looking for webpack 1 docs? Please check out the old wiki, but note that this deprecated version is no longer supported.

If you want to discuss something or just need help, here is our Gitter room where there are always individuals looking to help out!

If you are still having difficulty, we would love for you to post a question to StackOverflow with the webpack tag. It is much easier to answer questions that include your webpack.config.js and relevant files! So if you can provide them, we'd be extremely grateful (and more likely to help you find the answer!)

If you are twitter savvy you can tweet #webpack with your question and someone should be able to reach out and help also.

If you have discovered a 🐜 or have a feature suggestion, feel free to create an issue on GitHub.

License

Core Team

Tobias Koppers Core Founder of webpack

Johannes Ewald Loaders & Plugins Early adopter of webpack

Sean T. Larkin Public Relations Founder of the core team

Kees Kluskens Development Sponsor

Sponsoring

Most of the core team members, webpack contributors and contributors in the ecosystem do this open source work in their free time. If you use webpack for a serious task, and you'd like us to invest more time on it, please donate. This project increases your income/productivity too. It makes development and applications faster and it reduces the required bandwidth.

This is how we use the donations:

• Allow the core team to work on webpack
• Thank contributors if they invested a large amount of time in contributing
• Support projects in the ecosystem that are of great value for users
• Support projects that are voted most (work in progress)
• Infrastructure cost
• Fees for money handling

Premium Partners

Other Backers and Sponsors

Before we started using OpenCollective, donations were made anonymously. Now that we have made the switch, we would like to acknowledge these sponsors (and the ones who continue to donate using OpenCollective). If we've missed someone, please send us a PR, and we'll add you to this list.

Gold Sponsors

Become a gold sponsor and get your logo on our README on GitHub with a link to your site.

Silver Sponsors

Become a silver sponsor and get your logo on our README on GitHub with a link to your site.

Bronze Sponsors

Become a bronze sponsor and get your logo on our README on GitHub with a link to your site.

Backers

Become a backer and get your image on our README on GitHub with a link to your site.

Special Thanks to

(In chronological order)

• @google for Google Web Toolkit (GWT), which aims to compile Java to JavaScript. It features a similar Code Splitting as webpack.
• @medikoo for modules-webmake, which is a similar project. webpack was born because I wanted Code Splitting for modules-webmake. Interestingly the Code Splitting issue is still open (thanks also to @Phoscur for the discussion).
• @substack for browserify, which is a similar project and source for many ideas.
• @jrburke for require.js, which is a similar project and source for many ideas.
• @defunctzombie for the browser-field spec, which makes modules available for node.js, browserify and webpack.
• Every early webpack user, which contributed to webpack by writing issues or PRs. You influenced the direction...
• @shama, @jhnns and @sokra for maintaining this project
• Everyone who has written a loader for webpack. You are the ecosystem...
• Everyone I forgot to mention here, but also influenced webpack.

enhanced-resolve's Issues

Added node 4.x dependency in 3.1

Some people are still using an old version of node with webpack 1.13.0 and ts-loader 1.3.3, but ts-loader 1.3.3 references enhanced-resolve ^3.0.0, which now breaks with 3.1 requiring a newer version of node.

Shouldn't the added dependency make this 4.0?

Would you consider exposing a sync resolve function?

Both awesome-typescript-loader and ts-loader are presently rolling their own sync resolver functions. It'd be great to get official support for this directly. Is that something you'd consider supporting? I suspect there may well be others out there similarly implementing this by hand as well.

cc @jbrantly @s-panferov

RFC: Performance Proposal

I've been running lots of profiles to find the bottlenecks in our webpack build. Probably the biggest bottleneck right now is resolving requests.

To highlight this, I've created a simple test case for our build. Basically I intercepted all calls to Resolver.resolve during a build, and wrote the parameters passed to disk. Then I created a script that loaded the list of requests and used enhanced-resolve to resolve each of the requests, and also used resolve-from.

The results are pretty crazy, for 14850 requests:

• enhanced-resolve: 11601 ms
• resolve-from: 484 ms

Note that I didn't do much investigation into where this time is going, but I think that this project (and webpack) would benefit greatly from simplifying the architecture.

I'd prefer to see this library only respect an extensions option, and then stuff like custom description files (like bower.json or component.json) could be added via a loader (whose results could be cached). We could add support for browser fields and aliases the same way (cacheable loader).

resolve.mainFields doesn't support objects in package.json

Do you want to request a feature or report a bug?
This is a bug, though possibly an intentional omission.

What is the current behavior?
Sub-arrays in resolve.mainFields are completely ignored during module resolution.

Minimum and contrived working example with repro steps: https://github.com/sjbarag/webpack-mwe

What is the expected behavior?
A sub-array in resolve.mainFields can be used to access properties from an object in a module's package.json, as it was in webpack 1.x.

Please mention other relevant information such as the browser version, Node.js version, webpack version and Operating System.

• Operating System: Mac OS 10.12.6 "Sierra"
• Shell: Bash 4.4.12
• Node: 6.11.2
• npm: 5.3.0
• Webpack: 3.5.6 (though I've tested 2.0 and every minor version since)

---

This issue was moved from webpack/webpack#5638 by @sokra. Orginal issue was by @sjbarag.

parseQuery will be replaced with getOptions

Incompatibility with node fs api.

I'm not sure this is bugs or expected behavior.
Example: fileSystem.readFileSync(filename, "utf8"), not respect utf8 and always return Buffer.

Angular 2 app doesn't build with last version (v3.4.0)

Since last release I can't build my Angular4 app anymore, following error occurs:

ERROR in ./src/main.ts
Module not found: Error: Can't resolve './$$_gendir/app/app.module.ngfactory'
 @ ./src/main.ts 5:0-74
 @ multi ./src/main.ts

Had to revert to v3.3.0.

Nb: I use angular/cli v1.0.0-rc.2

bower component main field can be array

I bower, the main field in bower.json can be an array, e.g.: https://github.com/rstacruz/nprogress/blob/master/bower.json#L12 - would you merge a PR for that? Currently as a workaround you have to set aliases within the webpack.config.js for those libraries.

Should purge() clear _readJsonStorage?

By trying to solve this problem I realized that invoking purge()

CachedInputFileSystem.prototype.purge = function(what) {
    this._statStorage.purge(what);
    this._readdirStorage.purge(what);
    this._readFileStorage.purge(what);
    this._readlinkStorage.purge(what);
}

does not clear _readJsonStorage and just wanted to confirm if this is intended or not.

How do you create a Noop resolve plugin?

Hello! I'm trying webpack 2 and found the need to make a plugin. I would like to listen into when a module tries to resolve without actually attempting to resolve the file myself. I tried using done() in a similar manner to some of the other plugins like so:

    compiler.resolvers.normal.plugin('module', function (data, done) {
      console.log(data)
      done(null, data)
    })

But that gives several errors like the following (own custom log output):

ERROR (webpack)-hot-middleware/client-overlay
Module build failed: Error: ENOENT: no such file or directory, open '/Users/mcmullins/dev/apps/config-frontend/node_modules/webpack-hot-middleware/client-overlay'
    at Error (native)
 @ (webpack)-hot-middleware/client.js?path=__webpack_hmr&quiet=true 99:14-41
 @ multi main

I also looked into using this.doResolve() but I was entirely clear on how it should be used. Also it seems the signature for this.doResolve() has changed compared to the webpack 1.0 docs? Any help is appreciated, thank you.

Edit: After explaining this and playing with somethings in my code, I think I might be following a red herring? I'll update in a few.

Cannot read property 'lastIndexOf' of undefined

Sorry for the crappy title, hard to figure out something descriptive for this.

I'm trying to create a webpack resolver/plugin where something arbitrary (foo:bar:baz) is resolved to a filesystem location (after some async work figuring out which file).

This is kind of hard, as I can't seem to hook in to the resolve infrastructure "early enough". I've added a regular resolver plugin, but the apply() method isn't called before webpack fails with an error that it can't resolve the module I'm trying to find.

In webpack 1, I made this work by adding a plugin that set up a hook on compiler.resolvers.normal.plugin('module', () => {}), resolved the request asyncronously and called this.doResolve() with a new request, pointing to a concrete file.

In webpack 2, I managed to do mostly the same (I have to wait for the compilation event being emitted before the resolvers are initialized), but when I pass the modified request to the doResolve() method, it ends up crashing inside of enhanced-resolve (TypeError: Cannot read property 'lastIndexOf' of undefined). It looks like it's trying to find a package.json file. Not sure why this is needed, or how I can tell it to search a specific location for the file.

Any ideas? Suggestions? Are there any guides on how to make a totally custom resolver?

Stack trace:

/home/espenh/webdev/san/node_modules/webpack/node_modules/enhanced-resolve/lib/DescriptionFileUtils.js:84
  var i = directory.lastIndexOf("/"),
                   ^

TypeError: Cannot read property 'lastIndexOf' of undefined
    at cdUp (/home/espenh/webdev/san/node_modules/webpack/node_modules/enhanced-resolve/lib/DescriptionFileUtils.js:84:19)
    at /home/espenh/webdev/san/node_modules/webpack/node_modules/enhanced-resolve/lib/DescriptionFileUtils.js:50:17
    at /home/espenh/webdev/san/node_modules/webpack/node_modules/enhanced-resolve/lib/forEachBail.js:29:14
    at Array.<anonymous> (/home/espenh/webdev/san/node_modules/webpack/node_modules/enhanced-resolve/lib/DescriptionFileUtils.js:14:50)
    at Storage.finished (/home/espenh/webdev/san/node_modules/webpack/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:38:15)
    at /home/espenh/webdev/san/node_modules/webpack/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:69:9
    at Array.<anonymous> (/home/espenh/webdev/san/node_modules/webpack/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:182:20)
    at Storage.finished (/home/espenh/webdev/san/node_modules/webpack/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:38:15)
    at ReadFileContext.<anonymous> (/home/espenh/webdev/san/node_modules/webpack/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:69:9)
    at ReadFileContext.callback (/home/espenh/webdev/san/node_modules/graceful-fs/graceful-fs.js:78:16)

Angular 4 AOT build breaks with latest release

Angular 4 cli build with AOT switch fails with latest changes. Replaced latest npm package with older release and builds fine. Looks like 7/20 commit caused issues.

No export for DirectoryDescriptionFileFieldAliasPlugin ?

It's not exists in node.js file, I thought it would be there, need PR?

CachedInputFileSystem is imported but never used in ResolverFactory

Is that right? There seems to be no purpose to this line:

var CachedInputFileSystem = require("./CachedInputFileSystem");

https://github.com/webpack/enhanced-resolve/blob/master/lib/ResolverFactory.js#L11

webpack-dev-server fails to rebuild on watch

enhanced-resolve/lib/CachedInputFileSystem.js:145
			if(key.startsWith(what))
			      ^

TypeError: Cannot read property 'startsWith' of undefined
    at Storage.purge (enhanced-resolve/lib/CachedInputFileSystem.js:145:10)
    at Storage.purge (enhanced-resolve/lib/CachedInputFileSystem.js:150:9)
    at CachedInputFileSystem.purge (enhanced-resolve/lib/CachedInputFileSystem.js:259:20)
    at Watchpack.watcher.once (webpack/lib/node/NodeWatchFileSystem.js:42:26)
    at Object.onceWrapper (events.js:318:30)
    at emitTwo (events.js:125:13)
    at Watchpack.emit (events.js:213:7)
    at Watchpack._onTimeout (watchpack/lib/watchpack.js:142:7)
    at ontimeout (timers.js:469:11)
    at tryOnTimeout (timers.js:304:5)
    at Timer.listOnTimeout (timers.js:264:5)

Error when using webpack in watch mode

I have updated to the latest release of this library (3.4.0), and that caused the watch script I've added to package.json (actually it is just webpack -d -w) to break. It breaks with this error message:

/Users/daniel.rotter/Development/massiveart/sulu-minimal/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:145
			if(key.startsWith(what))
			      ^

TypeError: Cannot read property 'startsWith' of undefined
    at Storage.purge (/Users/daniel.rotter/Development/massiveart/sulu-minimal/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:145:10)
    at Storage.purge (/Users/daniel.rotter/Development/massiveart/sulu-minimal/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:150:9)
    at CachedInputFileSystem.purge (/Users/daniel.rotter/Development/massiveart/sulu-minimal/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:259:20)
    at Watchpack.watcher.once (/Users/daniel.rotter/Development/massiveart/sulu-minimal/node_modules/webpack/lib/node/NodeWatchFileSystem.js:42:26)
    at Object.onceWrapper (events.js:318:30)
    at emitTwo (events.js:125:13)
    at Watchpack.emit (events.js:213:7)
    at Watchpack._onTimeout (/Users/daniel.rotter/Development/massiveart/sulu-minimal/node_modules/watchpack/lib/watchpack.js:142:7)
    at ontimeout (timers.js:488:11)
    at tryOnTimeout (timers.js:323:5)
    at Timer.listOnTimeout (timers.js:283:5)
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! @ watch: `webpack -d -w`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the @ watch script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

The initial build works, but this error occurs after I save a file being watched. Is there some compatability issue with this release?

If I downgrade to version 3.3.0 of this library the watch task is working again.

package.json with utf-8 bom fails

Steps to reproduce:

1. npm and yarn install packages
2. the installed package has a package.json with utf-8 and bom (byte order marker)
3. webpack build fails with the following error

Module build failed: ModuleNotFoundError: Module not found: SyntaxError: <project>\node_modules\@nice\nice-fluorine-icons\pack
age.json (directory description file): SyntaxError: <project>\node_modules\@nice\nice-fluorine-icons\package.json (directory d
escription file): SyntaxError: Unexpected token  in JSON at position 0
    at factoryCallback (<project>\node_modules\@angular\cli\node_modules\webpack\lib\Compilation.js:260:39)
    at factory (<project>\node_modules\@angular\cli\node_modules\webpack\lib\NormalModuleFactory.js:247:20)
    at resolver (<project>\node_modules\@angular\cli\node_modules\webpack\lib\NormalModuleFactory.js:65:21)
    at asyncLib.parallel.e (<project>\node_modules\@angular\cli\node_modules\webpack\lib\NormalModuleFactory.js:138:21)
    at <project>\node_modules\async\dist\async.js:3838:9
    at <project>\node_modules\async\dist\async.js:421:16
    at iteratorCallback (<project>\node_modules\async\dist\async.js:996:13)
    at <project>\node_modules\async\dist\async.js:906:16
    at <project>\node_modules\async\dist\async.js:3835:13
    at resolvers.normal.resolve (<project>\node_modules\@angular\cli\node_modules\webpack\lib\NormalModuleFactory.js:130:23)
    at onResolved (<project>\node_modules\enhanced-resolve\lib\Resolver.js:64:18)
    at loggingCallbackWrapper (<project>\node_modules\enhanced-resolve\lib\createInnerCallback.js:31:19)
    at innerCallback (<project>\node_modules\enhanced-resolve\lib\Resolver.js:121:19)
    at loggingCallbackWrapper (<project>\node_modules\enhanced-resolve\lib\createInnerCallback.js:31:19)
    at <project>\node_modules\tapable\lib\Tapable.js:283:15
    at <project>\node_modules\enhanced-resolve\lib\UnsafeCachePlugin.js:36:19

Background:
we found a lenghty discussion on the npm repo. finally, npm implemented utf-8 bom handling since npm 3.x

At eslint, they also support utf-8 bom since eslint/eslint#6556

Shouldn't it be implemented in webpack then, too?

fails if extension missing in browser field left side

hey guys, ran into this issue:

works:

  "browser": {
    "./lib/blah.js": false
  }

doesn't

  "browser": {
    "./lib/blah": false
  }

Query not passed in aliased loader

I'm getting the same unexpected behavior as in webpack/webpack#1289. Aliased loaders do not receive query parameters. I checked the code and it seems the fix that was used before wasn't migrated with the new versions.

Node: v5.12.0
webpack: 1.13.2

Resolver for external filesystem

Hi, wondering whether this is a best fit for such use-case.
We have files in mongodb gridfs and would like to use webpack to process files within the gridfs.

Is writing a custom-resolver the right approach?

AliasFieldPlugin.apply + lodash: resolving the wrong toString

When resolving "./toString" from lodash, data2 on AliasFieldPlugin.js is removing the ./ from "./toString" of lodash, causing fieldData to get the default function toString() of every object.

Resulting in:

       var idxQuery = identifier.indexOf("?");
                                  ^

TypeError: identifier.indexOf is not a function
    at Resolver.parse (/Users/fcconstantino/Projects/@products/@crefisa/NetBankApp/node_modules/enhanced-resolve/lib/Resolver.js:181:28)
    at Resolver.<anonymous> (/Users/fcconstantino/Projects/@products/@crefisa/NetBankApp/node_modules/enhanced-resolve/lib/ParsePlugin.js:17:25)
    at Resolver.applyPluginsAsyncSeriesBailResult1 (/Users/fcconstantino/Projects/@products/@crefisa/NetBankApp/node_modules/tapable/lib/Tapable.js:256:13)
    at runNormal (/Users/fcconstantino/Projects/@products/@crefisa/NetBankApp/node_modules/enhanced-resolve/lib/Resolver.js:130:20)
    at Resolver.doResolve (/Users/fcconstantino/Projects/@products/@crefisa/NetBankApp/node_modules/enhanced-resolve/lib/Resolver.js:116:3)
    at Resolver.<anonymous> (/Users/fcconstantino/Projects/@products/@crefisa/NetBankApp/node_modules/enhanced-resolve/lib/UnsafeCachePlugin.js:37:12)
    at Resolver.applyPluginsAsyncSeriesBailResult1 (/Users/fcconstantino/Projects/@products/@crefisa/NetBankApp/node_modules/tapable/lib/Tapable.js:256:13)
    at runNormal (/Users/fcconstantino/Projects/@products/@crefisa/NetBankApp/node_modules/enhanced-resolve/lib/Resolver.js:130:20)
    at Resolver.doResolve (/Users/fcconstantino/Projects/@products/@crefisa/NetBankApp/node_modules/enhanced-resolve/lib/Resolver.js:116:3)
    at Resolver.<anonymous> (/Users/fcconstantino/Projects/@products/@crefisa/NetBankApp/node_modules/enhanced-resolve/lib/AliasFieldPlugin.js:49:12)

Something I couldn't find is: Who is calling the AliasFieldPlugin?

A simple and easy fix was to do something like this:

if (typeof data === 'function') {
    return callback();
}

OBS: I'm also using Haul, which uses an older version of webpack, but still the latest version of enhanced-resolve

Using	Version
npm	5.4.2
webpack	2.7.0
enhanced-resolve	3.4.1
lodash	4.17.4
haul	1.0.0-beta.5

Cannot read property 'startsWith' of undefined

._enhanced-resolve@3.4.0@enhanced-resolve/lib/CachedInputFileSystem.js:146
if(key.startsWith(what))

TypeError: Cannot read property 'startsWith' of undefined
at Storage.purge

Failed to rebuild with [email protected],throw exceptions that enhanced-resolve/lib/CachedInputFileSystem.js:145 if(key.startsWith(what))

/home/qd/project_1/fin-front/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:145
                        if(key.startsWith(what))
                              ^

TypeError: Cannot read property 'startsWith' of undefined
    at Storage.purge (/home/qd/project_1/fin-front/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:145:10)
    at Storage.purge (/home/qd/project_1/fin-front/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:150:9)
    at CachedInputFileSystem.purge (/home/qd/project_1/fin-front/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:259:20)
    at EventEmitter.<anonymous> (/home/qd/project_1/fin-front/node_modules/webpack/lib/node/NodeWatchFileSystem.js:42:26)
    at EventEmitter.g (events.js:260:16)
    at emitTwo (events.js:87:13)
    at EventEmitter.emit (events.js:172:7)
    at EventEmitter._onTimeout (/home/qd/project_1/fin-front/node_modules/watchpack/lib/watchpack.js:142:7)
    at Timer.listOnTimeout (timers.js:92:15)

I start up is ok but I edit the file failed,I use ubuntu 16.10

RFC Performance Improvement Opportunity

TLDR: Removing createInnerCallback sees a 2x performance boost.

I've been doing a lot of profiling of our webpack builds to see if there are any savings to be had. While doing this I noticed that there is a ton of garbage collection happening, and through that I found my way to this repository.

It seems that createInnerCallback creates many large arrays (full of strings) that go unused unless you're passing the --verbose flag, and your build has errors. There may be other use cases, but that's all I've been able to find.

How can we limit the impact here? I'd love to remove this log entirely as I don't see the value of it as an end user of webpack (webpack 3? 🤞 ), especially since disabling nets a huge performance win. If that's not possible can we expose an option to disable?

Charts!

• It's a little bit difficult to highlight, but notice in this call stack that after each loggingCallbackWrapper there is a garbage collection event.

• Here the calls to createInnerCallback have been removed (no more garbage collection).

Bottom up profile of our build before any changes:

After removing all the createInnerCallback calls:

Removing createInnerCallback calls + running with --max-semi-space-size=1000:

`lib/Resolve.js` has thrown an error under [email protected] and [email protected]

Recently I have upgraded node to version 7.4.0 and npm to 5.1.0 and failed to build my project with Webpack. In the gulp file, I have the following snippet:

webpack(require('./build/webpack/config-prod'), function(err, stats) {
    if (err) throw new gutil.PluginError('webpack', err);
});

But when I run it, I failed to build with following error logged out:

[gulp] /home/gitlab-runner/builds/4fb49748/0/coremail/cmj/template.NG/gulpfile.js:131
[gulp]         if (err) throw new gutil.PluginError('webpack', err);
[gulp]                  ^
[gulp] Error
[gulp]     at /home/gitlab-runner/builds/4fb49748/0/coremail/cmj/template.NG/node_modules/webpack/lib/Compilation.js:229:38
[gulp]     at onDoneResolving (/home/gitlab-runner/builds/4fb49748/0/coremail/cmj/template.NG/node_modules/webpack/lib/NormalModuleFactory.js:29:20)
[gulp]     at /home/gitlab-runner/builds/4fb49748/0/coremail/cmj/template.NG/node_modules/webpack/lib/NormalModuleFactory.js:85:20
[gulp]     at /home/gitlab-runner/builds/4fb49748/0/coremail/cmj/template.NG/node_modules/webpack/node_modules/async/lib/async.js:726:13
[gulp]     at /home/gitlab-runner/builds/4fb49748/0/coremail/cmj/template.NG/node_modules/webpack/node_modules/async/lib/async.js:52:16
[gulp]     at done (/home/gitlab-runner/builds/4fb49748/0/coremail/cmj/template.NG/node_modules/webpack/node_modules/async/lib/async.js:241:17)
[gulp]     at /home/gitlab-runner/builds/4fb49748/0/coremail/cmj/template.NG/node_modules/webpack/node_modules/async/lib/async.js:44:16
[gulp]     at /home/gitlab-runner/builds/4fb49748/0/coremail/cmj/template.NG/node_modules/webpack/node_modules/async/lib/async.js:723:17
[gulp]     at /home/gitlab-runner/builds/4fb49748/0/coremail/cmj/template.NG/node_modules/webpack/node_modules/async/lib/async.js:167:37
[gulp]     at /home/gitlab-runner/builds/4fb49748/0/coremail/cmj/template.NG/node_modules/enhanced-resolve/lib/UnsafeCachePlugin.js:24:19
[gulp]     at onResolved (/home/gitlab-runner/builds/4fb49748/0/coremail/cmj/template.NG/node_modules/enhanced-resolve/lib/Resolver.js:38:18)
[gulp]     at innerCallback (/home/gitlab-runner/builds/4fb49748/0/coremail/cmj/template.NG/node_modules/enhanced-resolve/lib/Resolver.js:88:19)
[gulp]     at loggingCallbackWrapper (/home/gitlab-runner/builds/4fb49748/0/coremail/cmj/template.NG/node_modules/enhanced-resolve/lib/createInnerCallback.js:21:19)
[gulp]     at /home/gitlab-runner/builds/4fb49748/0/coremail/cmj/template.NG/node_modules/tapable/lib/Tapable.js:134:6
[gulp]     at loggingCallbackWrapper (/home/gitlab-runner/builds/4fb49748/0/coremail/cmj/template.NG/node_modules/enhanced-resolve/lib/createInnerCallback.js:21:19)
[gulp]     at innerCallback (/home/gitlab-runner/builds/4fb49748/0/coremail/cmj/template.NG/node_modules/enhanced-resolve/lib/Resolver.js:94:11)

And my version of Webpack is 1.13.2

Is there any working around for solving the problem without upgrading Webpack?

Disable browser field.

Is it possible to disable browser field checking in this module?

Issue with leading dot on component definitions

Webpack seems to have problems with bower components defining the main file in a relative manner with a leading . (e.g.: https://github.com/Wolfy87/EventEmitter/blob/master/bower.json#L6) - is that something that is discouraged? If yes, I will continue to use aliases - if not, I might provide a PR to fix it.

Multiple modules support for alias

Hi, currently I have the following alias configuration, which then I need to remember to include both files whenever I want to use the component:

alias: {
  'ng-file-upload-shim5': 'ng-file-upload/angular-file-upload-html5-shim',
  'ng-file-upload-main': 'ng-file-upload/angular-file-upload'
}

But would like to have only one entry for both files, like this:

alias: {
  'ng-file-upload': [
    'ng-file-upload/angular-file-upload-html5-shim',
    'ng-file-upload/angular-file-upload'
  ]
}

What do you think?

Refactor forEach to for

See webpack issue for background

webpack/webpack#4031

3.4.0 breaks Angular CLI

Hi there,

It seems the recent 3.4.0 breaks @ngtools/webpack, which is at the core @angular/cli (angular/angular-cli#7113).

In the https://github.com/webpack/enhanced-resolve/releases/tag/v3.4.0 release I only see performance changes so am not too sure what changed that breaks our stuff.

Our direct usage of enhanced-resolve is contained in https://github.com/angular/angular-cli/blob/master/packages/@ngtools/webpack/src/paths-plugin.ts.

Is there anything that comes to mind we need to change to support ^3.4.0?

Thanks for your time.

Memoize calls to memory-fs join for performance

Calls to Resolver normalize can take up 5% to 8% of the build time. If we memoize these calls we can improve webpack build performance. Memoizing the join call seems to be the best place to intercept calls to memory-fs. I'll put up a PR if this sounds reasonable.

Before

After

RangeError: Maximum call stack size exceeded

I am getting this error while trying to run webpack (2) command on Azure:

\\100.78.172.13\volume-7-default\8f5ecde749dace2bb57a\4e07195f015b45ce8e9ba255dc901988\site\repository\Source\Website\Content\app\node_modules\webpack\node_modules\memory-fs\lib\normalize.js:19
    while(currentDirectoryWinMiddleRegExp.test(path))
                                          ^

RangeError: Maximum call stack size exceeded
    at RegExp.test (native)
    at normalize (\\100.78.172.13\volume-7-default\8f5ecde749dace2bb57a\4e07195f015b45ce8e9ba255dc901988\site\repository\Source\Website\Content\app\node_modules\webpack\node_modules\memory-fs\lib\normalize.js:19:40)
    at Tapable.join (\\100.78.172.13\volume-7-default\8f5ecde749dace2bb57a\4e07195f015b45ce8e9ba255dc901988\site\repository\Source\Website\Content\app\node_modules\webpack\node_modules\memory-fs\lib\join.js:13:9)
    at \\100.78.172.13\volume-7-default\8f5ecde749dace2bb57a\4e07195f015b45ce8e9ba255dc901988\site\repository\Source\Website\Content\app\node_modules\webpack\node_modules\enhanced-resolve\lib\DescriptionFileUtils.js:11:39

    at forEachBail (\\100.78.172.13\volume-7-default\8f5ecde749dace2bb57a\4e07195f015b45ce8e9ba255dc901988\site\repository\Source\Website\Content\app\node_modules\webpack\node_modules\enhanced-resolve\lib\forEachBail.js:12:3)
    at findDescriptionFile (\\100.78.172.13\volume-7-default\8f5ecde749dace2bb57a\4e07195f015b45ce8e9ba255dc901988\site\repository\Source\Website\Content\app\node_modules\webpack\node_modules\enhanced-resolve\lib\DescriptionFileUtils.js:10:3)

    at \\100.78.172.13\volume-7-default\8f5ecde749dace2bb57a\4e07195f015b45ce8e9ba255dc901988\site\repository\Source\Website\Content\app\node_modules\webpack\node_modules\enhanced-resolve\lib\DescriptionFileUtils.js:55:13
    at \\100.78.172.13\volume-7-default\8f5ecde749dace2bb57a\4e07195f015b45ce8e9ba255dc901988\site\repository\Source\Website\Content\app\node_modules\webpack\node_modules\enhanced-resolve\lib\forEachBail.js:29:14
    at \\100.78.172.13\volume-7-default\8f5ecde749dace2bb57a\4e07195f015b45ce8e9ba255dc901988\site\repository\Source\Website\Content\app\node_modules\webpack\node_modules\enhanced-resolve\lib\DescriptionFileUtils.js:15:50
    at Storage.provide (\\100.78.172.13\volume-7-default\8f5ecde749dace2bb57a\4e07195f015b45ce8e9ba255dc901988\site\repository\Source\Website\Content\app\node_modules\webpack\node_modules\enhanced-resolve\lib\CachedInputFileSystem.js:53:20)
    at CachedInputFileSystem.readJson (\\100.78.172.13\volume-7-default\8f5ecde749dace2bb57a\4e07195f015b45ce8e9ba255dc901988\site\repository\Source\Website\Content\app\node_modules\webpack\node_modules\enhanced-resolve\lib\CachedInputFileSystem.js:164:24)
    at \\100.78.172.13\volume-7-default\8f5ecde749dace2bb57a\4e07195f015b45ce8e9ba255dc901988\site\repository\Source\Website\Content\app\node_modules\webpack\node_modules\enhanced-resolve\lib\DescriptionFileUtils.js:13:25
    at forEachBail (\\100.78.172.13\volume-7-default\8f5ecde749dace2bb57a\4e07195f015b45ce8e9ba255dc901988\site\repository\Source\Website\Content\app\node_modules\webpack\node_modules\enhanced-resolve\lib\forEachBail.js:12:3)
    at findDescriptionFile (\\100.78.172.13\volume-7-default\8f5ecde749dace2bb57a\4e07195f015b45ce8e9ba255dc901988\site\repository\Source\Website\Content\app\node_modules\webpack\node_modules\enhanced-resolve\lib\DescriptionFileUtils.js:10:3)

    at \\100.78.172.13\volume-7-default\8f5ecde749dace2bb57a\4e07195f015b45ce8e9ba255dc901988\site\repository\Source\Website\Content\app\node_modules\webpack\node_modules\enhanced-resolve\lib\DescriptionFileUtils.js:55:13
    at \\100.78.172.13\volume-7-default\8f5ecde749dace2bb57a\4e07195f015b45ce8e9ba255dc901988\site\repository\Source\Website\Content\app\node_modules\webpack\node_modules\enhanced-resolve\lib\forEachBail.js:29:14
    at \\100.78.172.13\volume-7-default\8f5ecde749dace2bb57a\4e07195f015b45ce8e9ba255dc901988\site\repository\Source\Website\Content\app\node_modules\webpack\node_modules\enhanced-resolve\lib\DescriptionFileUtils.js:15:50
    at Storage.provide (\\100.78.172.13\volume-7-default\8f5ecde749dace2bb57a\4e07195f015b45ce8e9ba255dc901988\site\repository\Source\Website\Content\app\node_modules\webpack\node_modules\enhanced-resolve\lib\CachedInputFileSystem.js:53:20)
    at CachedInputFileSystem.readJson (\\100.78.172.13\volume-7-default\8f5ecde749dace2bb57a\4e07195f015b45ce8e9ba255dc901988\site\repository\Source\Website\Content\app\node_modules\webpack\node_modules\enhanced-resolve\lib\CachedInputFileSystem.js:164:24)
    at \\100.78.172.13\volume-7-default\8f5ecde749dace2bb57a\4e07195f015b45ce8e9ba255dc901988\site\repository\Source\Website\Content\app\node_modules\webpack\node_modules\enhanced-resolve\lib\DescriptionFileUtils.js:13:25
    at forEachBail (\\100.78.172.13\volume-7-default\8f5ecde749dace2bb57a\4e07195f015b45ce8e9ba255dc901988\site\repository\Source\Website\Content\app\node_modules\webpack\node_modules\enhanced-resolve\lib\forEachBail.js:12:3)
    at findDescriptionFile (\\100.78.172.13\volume-7-default\8f5ecde749dace2bb57a\4e07195f015b45ce8e9ba255dc901988\site\repository\Source\Website\Content\app\node_modules\webpack\node_modules\enhanced-resolve\lib\DescriptionFileUtils.js:10:3)

    at \\100.78.172.13\volume-7-default\8f5ecde749dace2bb57a\4e07195f015b45ce8e9ba255dc901988\site\repository\Source\Website\Content\app\node_modules\webpack\node_modules\enhanced-resolve\lib\DescriptionFileUtils.js:55:13
    at \\100.78.172.13\volume-7-default\8f5ecde749dace2bb57a\4e07195f015b45ce8e9ba255dc901988\site\repository\Source\Website\Content\app\node_modules\webpack\node_modules\enhanced-resolve\lib\forEachBail.js:29:14
    at \\100.78.172.13\volume-7-default\8f5ecde749dace2bb57a\4e07195f015b45ce8e9ba255dc901988\site\repository\Source\Website\Content\app\node_modules\webpack\node_modules\enhanced-resolve\lib\DescriptionFileUtils.js:15:50
    at Storage.provide (\\100.78.172.13\volume-7-default\8f5ecde749dace2bb57a\4e07195f015b45ce8e9ba255dc901988\site\repository\Source\Website\Content\app\node_modules\webpack\node_modules\enhanced-resolve\lib\CachedInputFileSystem.js:53:20)
    at CachedInputFileSystem.readJson (\\100.78.172.13\volume-7-default\8f5ecde749dace2bb57a\4e07195f015b45ce8e9ba255dc901988\site\repository\Source\Website\Content\app\node_modules\webpack\node_modules\enhanced-resolve\lib\CachedInputFileSystem.js:164:24)
    at \\100.78.172.13\volume-7-default\8f5ecde749dace2bb57a\4e07195f015b45ce8e9ba255dc901988\site\repository\Source\Website\Content\app\node_modules\webpack\node_modules\enhanced-resolve\lib\DescriptionFileUtils.js:13:25
    at forEachBail (\\100.78.172.13\volume-7-default\8f5ecde749dace2bb57a\4e07195f015b45ce8e9ba255dc901988\site\repository\Source\Website\Content\app\node_modules\webpack\node_modules\enhanced-resolve\lib\forEachBail.js:12:3)
    at findDescriptionFile (\\100.78.172.13\volume-7-default\8f5ecde749dace2bb57a\4e07195f015b45ce8e9ba255dc901988\site\repository\Source\Website\Content\app\node_modules\webpack\node_modules\enhanced-resolve\lib\DescriptionFileUtils.js:10:3)

Is this caused by my configuration or it's a bug in enhanced-resolve?

Webpack Watcher crashes when editing a file since last version

Version 3.4.0. The issue was not there in 3.3.0.
The following errors happens (+ stops the npm process), after saving a file, and the watcher refreshes.

`node_modules\enhanced-resolve\lib\CachedInputFileSystem.js:145
if(key.startsWith(what))
^

TypeError: Cannot read property 'startsWith' of undefined`

New resolve mechanism breaks directory named plugin

I'm trying to use the directory-named-webpack-plugin with webpack 2.1.0-beta.20, but unfortunately it breaks. It seems that some internals have changed: request.request and this.forEachBail are both undefined. I've gotten pretty far by adapting the CloneBasenamePlugin.

I've created an issue to document my findings.

Questions:

1. Is the plugin needed or can I do everything using CloneBasenamePlugin?
2. Is there any documentation how to create a directory resolver like this?

Concord modules?

We've got a rather large build, and after grep'ing through our codebase, it seems that none of our dependencies are using the concord field in package.json. Is this something that is still being pursued or could it be removed from enhanced-resolve?

npm link / potential memory leak issue

@pelotom reported an issue when using ts-loader (which uses enhanced-resolve). Details here: TypeStrong/ts-loader#420 (comment)

As you can see, @pelotom has now found a workaround and so isn't looking at this anymore. This is not my issue but I wanted there to be some visibility of a potential problem in case it's something that merits attention.

Bug: TypeError: Cannot read property 'startsWith' of undefined

I've been seeing this a lot this morning (full trace):

/Users/robcresswell/icing/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:145
			if(key.startsWith(what))
			      ^

TypeError: Cannot read property 'startsWith' of undefined
    at Storage.purge (/Users/robcresswell/icing/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:145:10)
    at Storage.purge (/Users/robcresswell/icing/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:150:9)
    at CachedInputFileSystem.purge (/Users/robcresswell/icing/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:259:20)
    at Watchpack.watcher.once (/Users/robcresswell/icing/node_modules/webpack/lib/node/NodeWatchFileSystem.js:42:26)
    at Object.onceWrapper (events.js:318:30)
    at emitTwo (events.js:125:13)
    at Watchpack.emit (events.js:213:7)
    at Watchpack._onTimeout (/Users/robcresswell/icing/node_modules/watchpack/lib/watchpack.js:142:7)
    at ontimeout (timers.js:469:11)
    at tryOnTimeout (timers.js:304:5)

It occurs any time a reload is prompted when using webpack-dev-server w/ hot-reload & Vue.

for Scripted

Issues from https://issuetracker.springsource.com/browse/SCRIPTED-117 @kdvolder

It doesn't do any caching (our current implementation builds an index of all the node_modules known to a given context. The index is thrown away if there are changes to any node_modules dirs. We will loose the benefit of this index if we switch to using the library. It may be this is ok, if the resolution is still fast enough. I may need to do a bit of performance testing to figure this out.

It does a bit of caching. It caches every io call for a short amount of time (currently fixed to 4 seconds), because webpack does many calls to resolve in parallel and that results in many similar io calls. It also combine parallel equal io calls to one. This libary is build for performance because resolving is a performance critical part of webpack.

For webpack we can assume that no revelant change will be made in these 4 seconds. For Scripted fast moves/renames may cause incorrect results. Not super critical, but Scripted may want to lower the timeout, or clear cache as it have already FileWatchers.

• make cache time configurable.
• make cache or parts clearable

It uses the node 'fs' functions directly. All our other code uses the filesystem only via a configurable api. This is now used mainly for testing purposes, but could also be important if we, want to use another filesystem implementation, e.g. to provide a sandboxed filesystem, or something that works completely client side, etc.

• offer config options for own io calls. This are stat and readFile each sync and async.

We were thinking of using a JSON5 parser instead of a straight JSON parser to improve error tolerance. Doing this (or making it an option) would require a patch to the enhanced-resolve library.

• offer a config option for the parse function.

code completion

enhanced-resolve can handle a part of that with require.context, but not code completion for module names. A part is already in a method but this is not availible on the interface.

• add methods to support this. Maybe something like a resolve method with wildcards...

Slow module resolution with several `modules` folders

Hi @sokra,

I faced with strange issue with very slow build and debugging showed that if I add several folder to modules, webpack will search in every additional folder several times even when target module can be found in the first folder. Is this behavior desired?

How to debug:

resolve: {
    modules: ['node_modules', '/folder1', '/folder2']
}

then add console.log here: https://github.com/webpack/enhanced-resolve/blob/master/lib/ModulesInRootPlugin.js#L23

do resolve /folder1 revjet-csp-data/src/Ontology.js
do resolve /folder2 revjet-csp-data/src/Ontology.js
do resolve /folder1 revjet-csp-data/src/Ontology.js
do resolve /folder2 revjet-csp-data/src/Ontology.js

And it seems like it grows in n^2 manner. For one folder there are two resolves, for two folders - 4 resolves.

Can't find any documenatation

The documentation link points to the front page of the Webpack wiki, which then links to the Webpack website. I can't find any documentation about what this module does or how to use it (although it looks very useful from looking at the code).

I want to know:

• Does this implement defunctzombie's browser field spec?
• If so, am I correct in understanding that enhanced-resolve is basically similar to browser-resolve, but with the added ability to provide your own filesystem to mediate/handle disk access?

It would be good to see at least one usage example in the readme.

CachedInputFileSystem - TypeError: Cannot read property 'startsWith' of undefined

Environment: Webpack 3.2.0, 3.3.0.

When it is used with babel-loader, webpack-dev-middleware (watch mode is on), sometime when a JS file changed, webpack is triggered to re-compile:

TypeError: Cannot read property 'startsWith' of undefined
    at Storage.purge (/Users/liujing/dianrong/dr-frontend/drcp-workspace/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:145:10)
    at Storage.purge (/Users/liujing/dianrong/dr-frontend/drcp-workspace/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:150:9)
    at CachedInputFileSystem.purge (/Users/liujing/dianrong/dr-frontend/drcp-workspace/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:259:20)
    at EventEmitter.watcher.once (/Users/liujing/dianrong/dr-frontend/drcp-workspace/node_modules/webpack/lib/node/NodeWatchFileSystem.js:42:26)
    at EventEmitter.g (events.js:291:16)
    at emitTwo (events.js:106:13)
    at EventEmitter.emit (events.js:191:7)
    at EventEmitter._onTimeout (/Users/liujing/dianrong/dr-frontend/drcp-workspace/node_modules/watchpack/lib/watchpack.js:142:7)
    at ontimeout (timers.js:365:14)
    at tryOnTimeout (timers.js:237:5)
    at Timer.listOnTimeout (timers.js:207:5) TypeError: Cannot read property 'startsWith' of undefined
    at Storage.purge (/Users/liujing/dianrong/dr-frontend/drcp-workspace/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:145:10)
    at Storage.purge (/Users/liujing/dianrong/dr-frontend/drcp-workspace/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:150:9)
    at CachedInputFileSystem.purge (/Users/liujing/dianrong/dr-frontend/drcp-workspace/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:259:20)
    at EventEmitter.watcher.once (/Users/liujing/dianrong/dr-frontend/drcp-workspace/node_modules/webpack/lib/node/NodeWatchFileSystem.js:42:26)
    at EventEmitter.g (events.js:291:16)
    at emitTwo (events.js:106:13)
    at EventEmitter.emit (events.js:191:7)
    at EventEmitter._onTimeout (/Users/liujing/dianrong/dr-frontend/drcp-workspace/node_modules/watchpack/lib/watchpack.js:142:7)
    at ontimeout (timers.js:365:14)
    at tryOnTimeout (timers.js:237:5)
    at Timer.listOnTimeout (timers.js:207:5)

I drilled down a little bit, found out, it was because babel-loader doing with loaderOptions.babelrc

var babelrcPath = null;
if (loaderOptions.babelrc !== false) {
babelrcPath = exists(fileSystem, loaderOptions.babelrc) ? loaderOptions.babelrc : resolveRc(fileSystem, path.dirname(filename));
}

So if I don't set an option babelrc for babel-loader, it might cache a undefined file name to CachedInputFileSystem via exist(), which is the target that.startsWith calls to later on.

I don't know why I can't reproduce in all Webpack projects, but I think calling .startsWith to a string without checking it with != null is problematic.

How do you plug this in to webpack?

How do you set the webpack resolver to the output of createResolver()?

feature request: could `resolve.alias` be greedy?

It seems that enhanced-resolve cannot handle different modules which have the same prefix.

resolve.alias = {
  antd: 'index',
  'antd/lib': 'components',
};

require('antd') => require('index');

// Now
require('antd/lib') => require('index/lib');

// If `resolve.alias` is greedy, and it is also what I want.
require('antd/lib') => require('components');

Or could you provide other solution which can do what I want? THX :-)

Resolve multiple files with a single require

I am working on a bower support plugin where I would like to resolve multiple files once a single require being called.

Lets say I do require('bootstrap') and this should include multiple files:

var mainModules = [
    'dist/js/bootstrap.js',
    'less/bootstrap.less'
];

Here is my test code:

    resolver.plugin('existing-directory', function (request, callback) {
        var mainModules = [];

        try {
            var source = require(path.resolve(request.path, 'bower.json'));
            mainModules = typeof source['main'] == 'string'
                ? [source['main']]
                : source['main'];
        } catch (e) {}

        if (mainModules.length == 0) {
            return callback();
        }

        mainModules.forEach(function (module) {
            var obj = Object.assign({}, request, {
                path: request.path + '/' + module
            });

            resolver.doResolve('file', obj, "file used: " + module, callback);
        });
    });

The problem is that only the first file is being included and others ignored. Is this behaviour possible with enhanced-resolver plugin? Any ideas or example would be welcome. @sokra

Why process commented line?

On Build, Why processing commented line?

ERROR in ./src/app/app.routes.ts 
Module build failed: Error: Can't resolve './+barrel' in
at onResolved (../node_modules/enhanced-resolve/lib/Resolver.js:66:16)

// app.routes.ts  
// Comments
//  { path: 'barrel', loadChildren: './+barrel#BarrelModule'},

ps - Using latest version3+.

Similar issue in angular aot build: Cannot determine the module for class
angular/angular#13590

Potentially on ng-router-loader:
shlomiassaf/ng-router-loader#3

Resolve main entry for bower and component

Hi!

I would like to see support out of the box in webpack for not only npm, but also the other very popular package managers, bower and component.

I'm guessing it should be a matter of adding this:

new DirectoryDescriptionFilePlugin("package.json", ["main"]),
new DirectoryDescriptionFilePlugin("bower.json", ["main"]),
new DirectoryDescriptionFilePlugin("component.json", ["main"]),

Thank you!

Flow complainis on `invalidPackageJson/package.json`

Hi, I'am truing out Flow, and have a problem with this module. Here what it is outputting:

$ flow 
Flow server launched for /Users/anon/projects/my/fluce
Spawned flow server (child pid=87549)
Logs will go to /var/folders/wt/s831gr6j4r38ffydyq0r2ft80000gn/T/flow/zSUserszSanonzSprojectszSmyzSfluce.log
The flow server will be ready in a moment.
Error: flow server is busyzing. If it was just started this can take some time. Retrying... |
Error: flow server is busyzing. If it was just started this can take some time. Retrying... -

/Users/anon/projects/my/fluce/node_modules/karma-webpack/node_modules/webpack/node_modules/enhanced-resolve/test/fixtures/node_modules/invalidPackageJson/package.json:1:3,2: Unexpected end of input

/Users/anon/projects/my/fluce/node_modules/webpack/node_modules/enhanced-resolve/test/fixtures/node_modules/invalidPackageJson/package.json:1:3,2: Unexpected end of input

Found 2 errors

As far as I understand, it scanning /node_modules/ for some reason, and fails on your broken fixture module. Could you, perhaps, exclude tests from npm package, by adding them in .npmignore? If you could do that, that would be great!

ES6 Translations

Tried to update some of the files to ES6 and encountered some linting errors while doing so. Is this happening because this project supports an older version of node or is it due to the configuration for eslint? @sokra would you mind clarifying this issue or pointing me towards the correct direction.

Backport preserve-symlinks fix to [email protected] for webpack@1

@sokra Could we get a backport to enhanced-resolve@~0.9?

create-react-app depends on [email protected] which depends on enhanced-resolve@~0.9 and when installing with pnpm to a global symlinked store (the fastest way to install deps currently and what yarn may support eventually), it does not work.

Is Bower supported?

I'm trying to mix npm and bower components in webpack2.

I have:

• lib/entry_point.js with require('bowerlib') intended for bower, and other npm requires
• bower_components/bowerlib/main.js with require('raven-js')
• bower_components/raven-js that specifies dist/raven.js as main.
• node_modules with lots of npm modules installed

I've tried:

• out of the box webpack2: can't find bowerlib
• config with resolve: {modules: [ __dirname + '/bower_components', 'node_modules']} - still can't find bowerlib
• config with resolve: {modules: [ __dirname + '/bower_components', 'node_modules'],mainFiles: ['index', 'main']} — it can find bowerlib, but can't find raven-js.
• resolve: {modules: [ __dirname + '/bower_components', 'node_modules'],mainFiles: ['index', 'main'],descriptionFiles: ["bower.json", "package.json"]} — hundreds of errors caused by failure to load npm modules from node_modules that worked otherwise.

Is it possible to use bower components? Is it possible with configuration, or do I have to write a custom plugin?