We currently write our JavaScript using native ES2015 modules.
To help us do this we use Browserify, which handles module bundling through the defined dependencies in each of our JavaScript files.
We also use Babel which allows us to write code using the latest syntax and features (ES6/ES2015/ES Next) while still providing support for older browsers. For more information on this, see the section on Babel below.
All of our JavaScript workflow tasks on the main global website are currently handled by Gulp, but our JavaScript modules are used by other teams using Webpack (which we may also move to in the future).
In order to help us stay up to date with the latest JavaScript features we write our modules using the features introduced in the ES2015 release.
As these new features are not widely supported across the browsers that we currently support, we make use of babelify & Babel to transform the code into ES5 and create a JavaScript bundle ready to serve in the browser.
As part of a drive to reduce JavaScript bundle sizes and remove unnecessary code from our codebase we write all of our modules using vanilla JavaScript, with a sprinkle of help via NPM packages where necessary.
JavaScript code conventions and best practices across projects at Just Eat are discussed and decided upon as part of the UI Guild. This is a regular meetup of UI Engineers across the company to ensure consistency in the way we develop, held each month. These conventions apply to all of the JavaScript code we write within web applications and NPM modules at Just Eat.
Thanks to these conventions it has become very easy for engineers to pick up a new codebase and get up and running quickly, as well as improving the onboarding process for new starters.
Any discussions are documented through Github issues and Pull Requests, and then when put into practice, should be documented in the relevant section of the fozzie documentation. All UI engineers are encouraged to feed back in to this process as we see our code conventions as an ever-evolving discussion rather than permanently set in stone.
For details on our agreed JavaScript coding conventions see the Code Style section.
All JavaScript code should include unit tests. We use the Jest framework.
See the JavaScript unit testing section for details on best practices and recommended coding styles.
We use Babel which allows us to write code using ES2015 syntax and then transform it back to ES5. This means that it is compatible with a wider variety of browsers.
To get an idea of what the transformed code will look like you can try out the Babel REPL.
This transformation happens as part of the gulp scripts build task – a task that is provided by the ‘gulp-build-fozzie’ NPM module.
We currently use the Babel env preset which takes a list of supported browsers (via a browserslist config) and only applies the transformations which are not supported by those browsers.
We use the Yarn package manager to handle our projects JavaScript module dependencies. Yarn is very similar to NPM with some small differences in performance and features.
Yarn shares the same package directory as NPM, so anything published on NPM can be installed as a Yarn module.
We use semver (Semantic Versioning) to version our NPM packages – to find out more about semver check out these semver docs.
To provide polyfills for features not widely supported, we use a service called Polyfill.io.
In short, Polyfill.io reads the User-Agent header of each request and returns polyfills that are suitable for the requesting browser. This means that the user only receives the polyfills they require to view our site (rather than providing a bundle of polyfills that all users would need to download).