Made.js is a library for MAterials DEsign in JavaScript allowing for the creation and manipulation of material structures from atoms up on the web. The library is aimed to be used for the development of web applications in JavaScript, both on the client (web browser) and server (eg. Node.js) side.
The library was originally designed as part of and presently powers materials design capabilities of the Exabyte.io platform. For example, this page representing a crystal of Silicon online uses Made.js.
Exabyte.io believe in a collaborative future of materials design on the web.
As below:
- the package provides a software environment for interacting with Materials-related data structures from ESSE Data Convention [1] and is written in ECMAScript 2015 for use on the web
- High-level classes for the representation of the Material and the corresponding structural information, ie:
- Basis,
- Lattice,
- ReciprocalLattice,
- Cell,
- AtomicConstraints
- and others to be added.
- input/output support, including:
- structural generation and analysis tools:
The package is written in a modular way easy to extend. Contributions can be in the form of additional tools or modules you develop, or feature requests and bug/issue reports.
From NPM for use within a software project:
npm install @exabyte-io/made.js
From source to contribute to development:
git clone [email protected]:Exabyte-io/made-js.git
This repository is an open-source work-in-progress and we welcome contributions.
We regularly deploy the latest code containing all accepted contributions online as part of the Exabyte.io platform, so contributors will see their code in action there.
We suggest forking this repository and introducing the adjustments there to be considered for merging into this repository as explained in more details here, for example.
Made.js is written in EcmaScript 6th edition [2] with the application of object-oriented design patterns encapsulating key concepts following the conventions below.
-
Classes follow the Exabyte Data Convention and data structures defined in ESSE [1]
-
Only materials-related code is considered. Properties related to simulation model parameters (eg. type of approximation, numerical parameters) shall go elsewhere.
-
tools
directory contains helper functions that act on one or more classes and include an external parameter. Functions that use class data without any external parameters should be implemented inside the class. For example,basis.clone()
is implemented inBasis
, but basis repetition is implemented as a tool in the correspondingly named function (tools/basis.js#repeat) because the repetion requires a parameter external to basis - number of repetitions in 3 spatial dimensions. -
parsers
directory contains the parsers to- and from- ESSE format mentioned in 1. All functionality related to external data conversion is contained in this directory.
Desirable features for implementation:
- identify primitive / conventional structures
- support for molecular geometries
- support for polymer geometries
- radial correlation function calculation
- generation of complex atomic shapes:
- fullerene
- nanotube
- nanowire
- nano-cluster
- a combination of the above
- arbitrary atomic arrangement
Made tests are written based on Mocha 6 testing framework and can be executed as follows.
git pull
git lfs pull
to get the latest test fixtures from LFS, and then:
npm install
npm test
-
Keep the tests directory structure similar to the main codebase directory structure. Every JS module in the main codebase should have a corresponding module in tests directory which implements the tests for provided functionality.
-
Add tests fixtures into fixtures directory. The fixtures are automatically stored on Git LFS 7.
-
If the fixtures are going to be used inside multiple cases, read and export them inside enums to avoid code duplicates.
-
Tests setup module can be used to implement the hooks that are used to prepare the tests environment.
Linter setup will prevent committing files that don't adhere to the code standard. It will
attempt to fix what it can automatically prior to the commit in order to reduce diff noise. This can lead to "unexpected" behavior where a
file that is staged for commit is not identical to the file that actually gets committed. This happens
in the lint-staged
directive of the package.json
file (by using a husky
pre-commit hook). For example,
if you add extra whitespace to a file, stage it, and try to commit it, you will see the following:
➜ made-js git:(feature/SOF-4398-TB) ✗ git add src/basis/constrained_basis.js
➜ made-js git:(feature/SOF-4398-TB) ✗ git commit -m "Test commit non-linted code"
✔ Preparing...
✔ Running tasks...
✖ Prevented an empty git commit!
✔ Reverting to original state because of errors...
✔ Cleaning up...
⚠ lint-staged prevented an empty git commit.
Use the --allow-empty option to continue, or check your task configuration
husky - pre-commit hook exited with code 1 (error)
The staged change may remain but will not have been committed. Then it will look like you still have a staged change to commit, but the pre-commit hook will not actually commit it for you, quite frustrating! Styling can be applied manually and fixed by running:
npm run lint:fix
In which case, you may need to then add the linter edits to your staging, which in the example above, puts the file back to identical with the base branch, resulting in no staged changes whatsoever.
In order for the WebStorm IDE to take full advantage of the linting configuration, it can be configured in the project:
Preferences -> Languages & Frameworks -> JavaScript -> Code Quality Tools -> ESLint
- Check
Automatic ESLint configuration
which should infer all the configurations from the project directory