Adding a build system?

[Ian Copp]

I've done a ton of work with JS build systems, so I'd be interested in putting one together here if you'd like to use one. This could be totally automated with Bitbucket Pipelines, so that whenever the master branch gets updated the build runs and then the final file bundle conveniently appears wherever you'd want it (ftp'd to somewhere, for example).

The benefits from it would be:

• No need to keep a copy of most libs in the repo (the final bundle would still have them included in the JS as part of the build)
• Total amount of code in the final bundle would be smaller (via "tree shaking" on the libs used)
• Moving to React components would be easier since proper JSX could be automatically compiled as part of the build
• An explicit import/export dependency tree would allow automatic code verification with tools like ESLint
• A bunch of code maintenance/improvements get way easier because you can use npm-based modules and polyfills

The disadvantages would be:

• To run it locally, people who want to change/test stuff would need to have node installed and know how to use a terminal/command prompt
• Keeping everything running as expected with Cordova might take some back and forth debugging (this depends a lot on the specific interactions of polyfills and stuff)
• The version number would need to change to have two dots instead of three (e.g. X.X.X, not X.X.X.X) because that's what node expects

[Arima B.]

Hi Ian, Maybe we can start small with something something as simple as code compression. I would probably avoid major refactoring due to the disadvantages you mentioned.

[Ian Copp]

Well, it is possible to get the basics of a build set up with minimum changes to existing code, but it would take adding a chunk of boilerplate to the top of each file, like:

const $I = window.$I;
const com = window.com;
const UIUtils = window.UIUtils;

...and similar boilerplate that attaches those to the window scope in the first place each is created, since with the build systems each file is in effect its own separate scope by default. I've done something similar before for an Angular 1 project, which has the same everything-in-the-global-scope problem. That approach would then allow breaking things off into new files with imports/exports one at a time.

That would still have the "need Node to work on it locally" limitation, though.