near
Bundle packages for NPM publishing
While working on separating out UI related packages for our monorepo, it made sense to do a quick investigation into Rollup for bundling these packages in order to support external consumers of these packages (EG: publishing to NPM).
I created a rough, working prototype branch that we can reference here: https://github.com/near/bos-web-engine/tree/feat/rollup-build-prototype
The biggest challenge I ran into was properly bundling packages/application and packages/compiler due to the dynamic worker import in useWebEngine(). Also, the @near-js/providers dependency used by the compiler package has dynamic imports to determine which environment (Node vs browser) the code is running in. My rudimentary Rollup config wasn't able to process these dynamic imports and kept throwing errors related to @near-js/providers. Rollup kept thinking we were importing a dependency that relied on the Node environment (access to https, buffer, process.env, etc). The only way to get around this was including a Rollup Node JS polyfill plugin - however, this just adds more bloat to the build.
The build process for the branch I referenced above does work, but the output for packages/compiler is a massive 9MB when using Rollup to bundle everything.
At some point we'll need to take a look at which packages we're wanting to publish to NPM and consider using some type of bundler like Rollup. Until then, we can assume our internal Next JS apps (web and sandbox) are the only consumers and Next JS can continue handling the bundling.
This is pertinent to discuss now since we will want to publish an npm package for SocialDB integration in the near future, possibly even for the alpha test. We do not necessarily need to settle the question for these other packages, but we will be adding an npm publish flow to the repo soon regardless so it would be nice to not incur tech debt with our approach
Part of my struggle is that I have zero experiencing publishing TS + React packages to NPM. If anyone has opinions or experience in this area, feel free to take lead on this.
Is this a requirement for publishing to NPM though? If the SPAs under /apps can consume them, can't external packages do the same?
What does Rollup get us over the tsc approach we're using now?
Good question @andy-haynes. The main reason we need a bundler like Rollup is to package the CSS Module styles along with our React components. I was able to make good progress on using Rollup in a non-disruptive way in my latest PR: https://github.com/near/bos-web-engine/pull/217
Since the packages/sandbox code was converted to CSS Modules, it also required being bundled with Rollup. However, I was able to set up @bos-web-engine/application as a peer dependency to avoid the issues outlined above. This allows your Next JS app to handle bundling of @bos-web-engine/application when using our UI components.
We'll probably need to revisit all of this once we're ready to actually publish packages to NPM.