RFC: Performance Proposal about enhanced-resolve

[mikesherov]

@gdborton, I think this is super interesting, but I was wondering if a different approach can work, where we introduce an option to use native resolution. That way, for most modules, you'd get the fast path of native resolution, with fallback to the other important resolvers (extensions comes to mind as an important one for React / Vue / Typescript) and other fast resolvers like the unsafeCachePlugin.

Thoughts?

[gdborton]

@sokra @mikesherov @TheLarkInn I'd love to unlock the performance potential here, but recognize that my proposed changes would mean a breaking change in both enhanced-resolve and webpack.

This is what I envision the config would look like after this change.

module.exports = {
  entry: 'somefile.js',
  output: {
    path: path.resolve('./dist'),
    filename: 'outputname.js',
  },
  module: {
    use: [
      // These loaders would transform the require statements, so that
      // enhanced-resolve only sees what is intended to be imported.
      {
        loader: 'bower-library-loader',
        include: ['./src']
      },
      {
        loader: 'alias-loader',
        aliases: {
          jquery: path.resolve('./bower_components/jquery'),
          path.resolve('./src/someFile'): path.resolve('./src/someOtherFile'),
        },
      },
    ],
  },
}

[gdborton]

@sokra poke.

[gdborton]

I'm guessing that would work for most people outside of aliasing and those still using bower. Native resolving works for any file so long as you provide the extension in your import.

[mikesherov]

Right but the key would fallback to slow manual resolution if fast resolution fails to find a module. So best of both worlds. You just wouldn't be able to do things like prioritize .vue over .js, etc.

[mikesherov]

so aliases are interesting in that some folks use them to override stuff that would otherwise still resolve.

[mikesherov]

So there's a tradeoff for sure. But I guess as a first step, you can inspect passed in options, and see if they match nodes native behavior, and if so, just go straight to native resolution.

[gdborton]

Do you think that this should be a change in webpack without looking at enhanced-resolve at all?

Something like...

try {
  // resolve-from
  resolveFrom(/* options */)
} catch(e) {
  // enhanced-resolve
  Resolver.resolve(/* options */);
}

Or would this take place in enhanced-resolve and would be transparent to webpack?

I'm guessing the latter...

[mikesherov]

I'm guessing latter, especially since it's a resolve option, which are automatically passed to a resolver factory.

[blowery]

We're doing some profiling of the build for https://github.com/Automattic/wp-calypso and finding similar results; we're spending a lot of time resolving requests. However, we also use aliases heavily...