feat(v2): site client modules

[slorber]

Motivation

As of today, it's a bit boilerplaty to add some global JS to a site, as you need to create a local site plugin to implement getClientModules.

The following option makes it more idiomatic as you can directly pass the client modules as a config attribute:

siteConfig.clientModules = [myGlobalJsPath, myGlobalCssPath]

See also RN website PR: react-native-website-migration/react-native-website@b75a0e6#diff-20b869a62a5a74fb46c979edc17980f6R1-R19

Have you read the Contributing Guidelines on pull requests?

Yes

[docusaurus-bot]

Deploy preview for docusaurus-2 ready!

Built with commit 2f835d6

https://deploy-preview-3545--docusaurus-2.netlify.app

[lex111]

I'm not familiar with this code, but surely removing the clientModule.__esModule won't affect it in any way? It was kind of related to Yarn 2 support (not sure)

[slorber]

This is a behavior change that shouldn't break anything, but allows you to write client lifecycle methods as named exports.

Before we had to use this syntax to add the lifecycle to default expor

export default {
    onRouteUpdate({location}) {
      console.log('onRouteUpdate', {location});
    },
};

Now we can also write the following:

export function onRouteUpdate({location}: {location: Location}) {
  console.log('onRouteUpdate', {location});
}

Note it's not a documented feature (yet) and kind of broken, so I plan to improve this as part of #3399

[slorber]

BTW both versions still work, and it's the default export that is picked in priority if both are used, so it should be retrocompatible in all cases even if it's not very likely that such code exist in userland

export function onRouteUpdate({location}: {location: Location}) {
  console.log('onRouteUpdate', {location});
}

export default {
  onRouteUpdate: function onRouteUpdate({location}: {location: Location}) {
    console.log('default onRouteUpdate', {location});
  },
};

[lex111]

Thanks for the explanation, so this is safe for merge.