search

canonical-web-and-design / practices

Guides and principles from the web team at Canonical and Ubuntu
https://canonical-web-and-design.github.io/practices/
Other
44 stars 30 forks source link

Add note about build tools to javascript doc. #174

Closed squidsoup closed 5 years ago

squidsoup commented 5 years ago

Rollup has generally been considered the standard tool for building libraries in the js community, largely in part to its ability to produce more efficient builds due to scope hoisting.

Webpack however has supported scope hoisting via the ModuleConcatenationPlugin which is the default for production mode builds since v3. This possibly removes one of the more compelling reasons to use Rollup.

The only potential argument for continuing to use Rollup for library builds is that it is generally easier to configure. Whether this incurs additional cognitive overhead, or actually makes things easier for us is probably something the team should discuss. While I'm not opposed to us using both tools, as an experiment, perhaps we should try to configure a similar Webpack build for one of our projects currently using Rollup.

bartaz commented 5 years ago

The only potential argument for continuing to use Rollup for library builds is that it is generally easier to configure. Being a little bit of a devils advocate here: if Rollup is easier to configure and has feature parity with WebPack why do we want to try using WebPack for all projects instead of using Rollup for everything?

We mover from Rollup to WebPack in snapcraft.io some time ago, because once we started having more JS functionality, modules, React and Redux we had build performance issues that made development process harder (slow build, changes to some modules not detected by watch, etc). But maybe it was just the matter of adjusting Rollup config or some tooling that we used for build?

If our goal here is to have potentially one build tool to rule them all this possibly can be webpack. If we can figure out the configuration for the 'library' build for webpack it should be quite straightforward to just reuse it whenever needed without having to learn complicated config settings.

On the other hand I don't really mind having two different tools if one seems to be easier to configure for library builds (rollup) and the other seems to be more suited for application builds (good support for plugins for babel, css modules, react, fast and reliable watch, hot reloading, etc).

squidsoup commented 5 years ago

Thanks @bartaz are you +1 then?

bartaz commented 5 years ago

Yes, 👍 from me.

Although prettier seems to fail in CI. Not sure if it's related to this PR. Are we checking .md files for code style?

nottrobin commented 5 years ago

Thanks @squidsoup this is great.

The only potential argument for continuing to use Rollup for library builds is that it is generally easier to configure. Whether this incurs additional cognitive overhead, or actually makes things easier for us is probably something the team should discuss. While I'm not opposed to us using both tools, as an experiment, perhaps we should try to configure a similar Webpack build for one of our projects currently using Rollup.

If appears that Rollup is our current standard for packages, so let's write it down that way for now, and then we can update it as it evolves.