does this need to be browser?

in all honesty, yes it does, doesn't it? We don't really have any instance of a backend web-server for webui. Even in ipfs-desktop, it's "serving" the content from assets/webui as a basic webpage using https://www.electronjs.org/docs/latest/api/browser-window and https://www.electronjs.org/docs/latest/api/web-contents

So in all honesty, this is a very lazy way to not split up the build deps from the runtime deps, but we're not quite there yet.

optional perf, check if not the end $ instead of check if element is one of everything-set .

        'multiformats/bases/([^$]+)$': '<rootDir>/node_modules/multiformats/cjs/src/bases/$1.js'

we should at least check the size + [1...inf] instead of * [0...inf]

        'multiformats/bases/(.+)$': '<rootDir>/node_modules/multiformats/cjs/src/bases/$1.js'

There really shouldn't be any performance difference, and if anything, it should be more performant with the greedy match. we already know the size is > 0 because of the forward-slash in front of X in imports of multiformats/bases/X, and we want to replace everything, so the regex engine doesn't have to double/triple check endings/beginnings/counts at all.. just.. get everything.

I put together a quick hyperfine test by doing

  jest: (config) => {
    let mfBases = 'multiformats/bases/(.*)$'
    if (process.env.MFBASE === '1') {
      mfBases = 'multiformats/bases/(.+)$'
    } else if (process.env.MFBASE === '2') {
      mfBases = 'multiformats/bases/([^$]+)$'
    }
    /**
     * @type {import('jest').Config}
     */
    return ({
      ...config,
      setupFiles: [...config.setupFiles, 'fake-indexeddb/auto'],
      moduleNameMapper: {
        ...config.moduleNameMapper,
        'multiformats/basics': '<rootDir>/node_modules/multiformats/cjs/src/basics.js',
        [mfBases]: '<rootDir>/node_modules/multiformats/cjs/src/bases/$1.js'
      }
    })
  }

and running

╰─ ✔ ❯ hyperfine 'MFBASE=0 npm run test:unit' 'MFBASE=1 npm run test:unit' 'MFBASE=2 npm run test:unit'
Benchmark 1: MFBASE=0 npm run test:unit
  Time (mean ± σ):      5.429 s ±  0.104 s    [User: 3.829 s, System: 1.008 s]
  Range (min … max):    5.232 s …  5.587 s    10 runs

Benchmark 2: MFBASE=1 npm run test:unit
  Time (mean ± σ):     17.498 s ± 24.296 s    [User: 4.158 s, System: 1.064 s]
  Range (min … max):    5.483 s … 63.602 s    10 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet PC without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Benchmark 3: MFBASE=2 npm run test:unit
  Time (mean ± σ):      5.675 s ±  0.114 s    [User: 3.911 s, System: 1.042 s]
  Range (min … max):    5.548 s …  5.919 s    10 runs

Summary
  'MFBASE=0 npm run test:unit' ran
    1.05 ± 0.03 times faster than 'MFBASE=2 npm run test:unit'
    3.22 ± 4.48 times faster than 'MFBASE=1 npm run test:unit'

npm/jest actually stalls out on MFBASE=1, below is the output when running MFBASE=1 npm run test:unit directly.

Jest did not exit one second after the test run has completed.

This usually means that there are asynchronous operations that weren't stopped in your tests. Consider running Jest with `--detectOpenHandles` to troubleshoot this issue.

MFBASE=0 actually has two additional checks for the process.env.MFBASE whereas the other two do not, so it's saying something that it's still faster.

Either way, optimizing regex here is.. tedious =P

in the future we should look into dotenv

This is basically a no-op if things are up to date, but required if any playwright updates are done (which were in this PR)

No need to disable this anymore. https://github.com/storybookjs/storybook/blob/next/MIGRATION.md#react18-new-root-api

getting ready for v7

fixes some issues with imports that don't have proper export fields; or our tools (playwright/storybook) that don't handle ESM packages properly.

will be able to remove when import-js/eslint-plugin-import#2701 is merged

currently skipping this due to some issues, but this was only added to address concerns with #2033 and isn't really a valid test.

will create an issue to address this

had to change this test to handle the removal of module mocks

had to change how we were loading icons because require.context isn't available. we export all icons from index.js, so importing them all from there.