Natural Pacifist Manatees

    TypeScript icon, indicating that this package has built-in type declarations

    1.1.2 • Public • Published


    atomist sdm goals npm version

    This project defines two stages of project analysis, which can be used to drive delivery decisions and to classify projects.

    The two stages are:

    • Project Analysis: First phase. Takes the project source code and builds an analysis that may be persisted. The most important part of a ProjectAnalysis is the elements property, whose value is an indexed type which values of type TechnologyElement. Because a ProjectAnalysis is designed to be serialized and persisted it contains only data, and no functions.
    • Interpretation: Second phase. Requires a ProjectAnalysis but not source code, so can be run on persisted analyses. An Interpretation is computed when necessary and not serialized to JSON, so it can specify functions and delivery goals.

    Analysis and interpretation is designed to be extensible. Additional "scanners" and "interpreters" can be added wtihout affecting existing capabilities.

    Two additional concepts are principally relevant to offline use, to classify projects and provide a basis for project querying:

    • Seed analysis: The ability to use multiple TransformRecipeContributor implementations to contribute parameters and transforms that can enable any project to be used as a seed. This "contribution" model ensures that we avoid the Cartesian product problem with seeds: E.g. if we care about AWS Lambda and Kubernetes, Node and Spring, we don't need 4 distinct generators (Lambda/Node, Lambda/Spring, Kube/Node and Kube/Spring), but can use one "universal" generator that applies whichever contributions are relevant to the current seed.
    • Project scoring: The ability to attach scores to an interpretation for various dimensions of a project, and to calculate a weighted composite score based on individual scores.

    Seed analysis is only performed when a project analysis is performed with the full option flag set to true. Scanner registrations that return technology elements can also specify whether or not they should fire depending on the invocation options. This is important for scanners that are expensive, such as calculation of the number of lines of code in a repository, which requires reading every file. Typically, such analyses are performed only infrequently, and persisted for future use.

    Getting started

    See the Developer Quick Start to jump straight to creating an SDM.


    Contributions to this project from community members are encouraged and appreciated. Please review the Contributing Guidelines for more information. Also see the Development section in this document.

    Code of conduct

    This project is governed by the Code of Conduct. You are expected to act in accordance with this code by participating. Please report any unacceptable behavior to


    Please see [][atomist-doc] for developer documentation.


    Follow @atomist and The Composition blog related to SDM.


    General support questions should be discussed in the #support channel in the Atomist community Slack workspace.

    If you find a problem, please create an issue.


    You will need to install Node.js to build and test this project.

    Build and test

    Install dependencies.

    $ npm install

    Use the build package script to compile, test, lint, and build the documentation.

    $ npm run build


    Releases are handled via the Atomist SDM. Just press the 'Approve' button in the Atomist dashboard or Slack.

    Created by Atomist. Need Help? Join our Slack workspace.


    npm i @atomist/sdm-pack-analysis

    DownloadsWeekly Downloads






    Unpacked Size

    303 kB

    Total Files


    Last publish


    • atomist-bot
    • cdupuis
    • slimslenderslacks