A bit of clarification about possible performance loss

[itsweliton]

Hi @Beej126, I was looking for some solution that could help me out go through the setup using create-react-app and single-spa.

I found this repo, I'd like to know if this setup caused any visible loss of performance while running the applications?

Since this discussion implies that bundling all the code together could lead to performance loss

[Beej126]

@welitonderesende - it's a fine question and we're not far enough along to have any sense of that yet... i'll try to remember to report back here once our code base behind this puts on some real weight

[samuelcastro]

Hi @Beej126 any updates on that, I'm going to start a project from scratch and I don't want to eject from CRA, would be great to see your findings on this.

[samuelcastro]

I guess my question is: are you comfortable with CRA for single-spa?

[Beej126]

The basic mechanics are solid. Rescripts is solving everything we've run into needing to customize webpack and jest and it feels very clean & concise... it feels great to rather blindly leverage webpack's optimizations and then just override the little bits as we come to each need... we've rolled from react-scripts 1.8 last year through 2.x to 3.2 already without a hitch.

After getting this much under my belt, I can finally comprehend CanopyTax's coaching about "import maps" as the answer for letting wepback do it's usual code splitting bundles in the microspas... but haven't quite gathered the need or mojo to go finish that off in our environment.

Like anything, make sure you really need the benefit vs the overhead. For example, maybe wait till you have the need to diverge into multiple front end frameworks (e.g. React + Blazor or Angular)... it's a bit silly for us since we're currently doing them all in React anyway... no surprise, you wind up wanting to share logic & components across all those individual spas... we went with an internal npm package which is then it's own overhead to debug locally (Tip: npm link) and manage versions updates across microSpas...

I've held the line on Typescript and am happy for it, so another tip is just leave your npm package in typescript as well and just publish the src folder as root... in the build script, copy copy package.json to src\ and npm publish from within src... this makes everything available at root like typical packages... in your consuming spas, override webpack's default avoidance of node_modules/{your package} with a rescripts override of webpackConfig.module.rules, like:

//we need to tell webpack to transpile our lims-shared-ts library because it is published as typescript
//unlike other npm packages that are already transpiled
//we did this because it's internal and we can take advantage of the simplicity of publishing the typescript src as-is
//also, we ran into typescript ENUMs not actually coming through from shared with vscode intellisense when transpiled to .js + .d.ts files
//that doesn't seem right to me so there may be some other configuration that would resolve that
//but it was another little  motivation to go with direct publishing of typescript
var codeRule = webpackConfig.module.rules //scan the existing rules...
    .filter(obj => !!obj.oneOf)[0].oneOf //find the rule with "oneOf" property which includes all the code transformations
    .filter(o2 => !!o2.test && o2.test.toString().indexOf("tsx") !== -1)[0]; //then drill down to the one that does typescript transpile

//finally, include the lims-shared package (along with this project's "src" folder sitting there)
//had to be very careful with this regex...
// "@kingcounty\/lims-shared-ts" didn't match for some reason... maybe logic considered it as a folder vs @prefix
codeRule.include = [codeRule.include, /@kingcounty.lims-shared/];