Consider a third-party build system

[joeyparrish]

It might be time to look at a third-party build system with dependency tracking. The existing build scripts are all custom and written in python, which made sense for a long time. Now, with the upcoming addition of a generated localization file, this file will be a dependency for gendeps, the compiler check we run over the tests, and the actual library builds.

It might be cleaner to have a third-party build system that tracks dependencies and supports intermediate build products. In such a system, customizing the build and other command-line flags would fall more into the "configure" script role.

[TheModMaker]

One option may be Bazel. Their JavaScript support is based mostly on NodeJS and TypeScript. But there are plugins for building with the closure compiler and for running tests with karma. We can generate the localizations with a genrule.

[joeyparrish]

One thing I worry about with Bazel is that it may be too much a Google-centric way of doing things. I wonder if there might be another tool which is more popular in open source in general, which would be more familiar to external developers.

But perhaps projects similar to ours may have no need for dependency tracking, so a build system like Bazel might be the right tool.

Or yet another possibility: perhaps if our build were not so slow, we would not need dependency tracking. We could just remake everything every time if it were reasonably fast.

[chrisfillmore]

Just a thought if you're looking at the build/test setup: we recently dropped Karma in favour of a small custom JSDom setup for unit tests and are 1000% happier. Your project is bigger than ours though so maybe you'd like to use headless Chrome or adopt Jest (which I think uses JSDom anyway)? Tests would run faster.

[joeyparrish]

Sadly, JSDom is a non-starter, since we have to integration test our interactions with the browser's media stack. It would be fine for unit tests, but we have to find platform incompatibilities and run tests in real browsers. We currently have 15 different real browser platforms we test on nightly.

[chrisfillmore]

Yeah I meant just for unit tests. I think this would cover a lot of development use cases. My contributions, at least, rarely affect the media stack, so I never run the integration tests. At least in our project, we have separate tools for running unit versus integration/e2e tests.

[mimse]

Two most popular build tools are webpack and rollup, not sure if they would cover the needs.

[avelad]

I think that webpack is a feasible option because has many plugin and it's easy write one according your necessities

[sgammon]

huge vote for Bazel

[sgammon]

webpack can run inside bazel now via rules_nodejs

[sgammon]

(Although it's worth noting that rules_closure is way smoother if things are pre-annoted for Closure)