pre-release analysis branch

[stackedq]

Recently I figured there are circular imports in redux selectors which resolved to some meaningless console errors and hard time for devs to find what's causing the problems.

I found a webpack plugin: circular-dependency-plugin which will show up the circular imports in the terminal, but since all of them are not necessarily errors, I don't think this plugin should live in the develop, release/*, or main branches.

I think a pre-release-analysis branch would do the job though.

We can also use other good webpack plugins like:

• webpack-bundle-analyzer to see the size of webpack output files with an interactive zoomable treemap. lodash is my primary concern here.
• generate-package-json-webpack-plugin to make sure no unused dependency is installed.
• css-cleanup-webpack-plugin to remove unused css and duplicated css rules.
• ...probably more dope plugins out there to be integrated

or even some integrations like cyperss-ios to make sure we're ready for the release up ahead.

This is just an idea, please feel free to share your thoughts, thanks.

[GMSteuart]

@stackedq I did a lot of research into existing plugins and GitHub actions that are out there and have been wanting to implement this. I'm surprised I didn't see this discussion before. In regards to the cypress-ios idea, I personally would like to see a test or stage branch created that is solely for running the entire suite of tests against. Then the branch, say feature-xyz, that will get merged into test, would only run tests for the modified files in the feature-xyz branch.

Then there would be another branch, like you said pre-release-analysis (what came to my mind was performance, perf, and speed) though there is also the possibility of having this be it's own repo or even a submodule in the monorepo. I do believe that at the minimum keeping track of key statistics like bundle size are a must have to properly monitor application performance. I would like to see things like automated lighthouse runs not only for performance but that we are also meeting web accessibility standards.

In regards to the css optimization, PostCSS needs to be a requirement, as well as Autoprefixer to ensure our styles are consistent across all browsers irrelevant of any IE support, and lastly, cssnano for optimizing the final CSS output. The main thing to take into account with optimizing CSS performance though is moving away from CSS-in-JS to a vanilla approach using className. This then also brings into question what preprocessor the development team will settle on between: Sass, Less, and Stylus; CSS preprocessors are an entirely new discussion.

All in all, I am in favor for the creation of additional branches for performing specific development operations.