RFC Performance Improvement Opportunity about enhanced-resolve

[sokra]

we can resolve without log first and in case of an error we do an additional resolve with log.

[gdborton]

@TheLarkInn @sokra thoughts?

[TheLarkInn]

Wow. This def seems like a huge win. Thanks for tagging us (GitHub notifications are the worst :( )

I'm all for this change. do you have a partial implementation so far?

PS: Congrats on submitting your first webpack/enhanced-resolve issue 🎉 🍾

[TheLarkInn]

@sokra we could probably decouple the logger a bit better and just pass a debug flag to the resolver/factory.

TBH I only ever see this information actually show when I'm working on enhanced-resolve locally, and never during a webpack build even with --verbose. So maybe we could remove it entirely except for when local development like you mentioned.

[gdborton]

I don't have any implementation in mind as I wasn't sure how else the log might get used. Personally I'd rather see it removed completely (or maybe only available through an internal flag?).

I don't really like the idea of adding an option for disabling a feature no one uses. Especially considering the biggest hurdle to adopting webpack is the config.

I don't mind doing the work though if we can find a reasonable solution.

[TheLarkInn]

I agree I think we should just have it as part of our test fixtures and local Dev if needed. It is very helpful for resolver plugin Dev also.

[niieani]

If you run webpack programatically, you can use this workaround (prior to requiring webpack) to get the above mentioned speed bump:

// useful Webpack performance benefit until this is resolved: https://github.com/webpack/enhanced-resolve/issues/88
const Module = require('module')

function createCallbackMock(callback, options, message, messageOptional) {
  return function callbackMock() {
    // eslint-disable-next-line prefer-rest-params
    return callback.apply(this, arguments)
  }
}

// magic for mocking modules
const originalLoad = Module._load
function mockModuleLoader(...mocks) {
  Module._load = function load(request, parent, isMain) {
    for (const mock of mocks) {
      const mockedModuleExports = mock(request, parent, isMain)
      if (mockedModuleExports !== undefined) {
        return mockedModuleExports
      }
    }
    return originalLoad.apply(undefined, arguments)
  }
}

// let's mock the 'createInnerCallback' file:
const createCallbackRegExp = /\/enhanced-resolve\/lib\/createInnerCallback.js$/
mockModuleLoader(
  (request, parent, isMain) => {
    const filename = Module._resolveFilename(request, parent, isMain)
    return createCallbackRegExp.test(filename) ? createCallbackMock : undefined
  }
)

This effectively replaces the module.exports of the createInnerCallback.js file with a dummy method.

[TheLarkInn]

Actually now that I think about this, we could leave as an empty fn and patch the logger when needed.

[ljharb]

I like that approach in general; it pushes all the perf cost to the error path, which doesn't matter if it's fast or not.

[mikesherov]

OK, so it seems like we make a new function like doResolveWithLogging that'll call doResolve and on error, recall doResolve with the createInnerCallback version attached?

[TheLarkInn]

That sounds right to me.