how do i declare global mappings ? about espub HOT 6 OPEN

Hi @lgersman !

Since v0.0.18, nanobundle has "standalone mode", which tries to inline all dependencies. In standalone mode, you can specify explicitly which dependency will not be inlined.

https://github.com/cometkim/nanobundle/tree/v0.0.18#embedding-dependencies

I'm not sure this option and microbundle's option you mentioned is met your requirement.

Can you provide some esbuild or rollup config you use for it?

from espub.

Hello @cometkim,

the reason for my question is that i would like to use your nanobundle to bundle Wordpress Gutenberg blocks. These blocks consists of Javascript running in the browser inside the Gutenberg Editor.

The Gutenberg Editor provides React and many of the @wordpress/* packages via global variable windows.wp (Example: import { Button } from ''@wordpress/components'; is available in the browser via const { Button } = windows.wp.components;).

That means that these packages dont need to be bundled but transpiled to access the import using global variables (like window.React and window.wp.components).

in Rollup you would declare that like this :

const config = {
    input: 'foo.js,
    output: {
      file: `dist/foo.js`,
      format: 'iife',
      globals: {
          react: 'React',
          '@wordpress/components': 'wp.components'
      },
      ....
    },

The transpilation is also possible using esbuild (see here : https://github.com/lgersman/ix-article-esbuild-2021/blob/develop/bin/esbuild-bundle.mjs#L64)

from espub.

Ok, I understand your requirement.

I'm trying to keep the config of nanobundle as simple as possible. I could also explore a good place for additional config per dependency in package.json (e.g. peerDependencyMeta), but I think import maps would be a simpler way to do this.

vendor/wp-components.js

export const {
  Button,
} = window.wp.components;

import-maps.json or package.json

{
  "imports": {
    "@wordpress/components": "./vendor/wp-components.js"
  }
}

from espub.

Good morning,

I understand your reasons (simplicity !) but some packages may expose dozens of exports ... which will result in a huge amount of import map code.

Don't you think there is a better way to expose globals ?

from espub.

Of course, simplicity is important, but there is another big problem here.

Adding personal opinions without esbuild config already existing or well-known standards is against the goal of the nanobundle.

Maybe it makes sense to provide an escape hatch that allows custom plugins for other cases.

from espub.

from espub.