andrewjensen / hekla Goto Github PK

TODO:

• Create hekla-webpack-plugin package
• Trigger on all files
• Read from the filesystem provided by webpack
• Create output file

We need integration tests for the webpack plugin package, to make sure there are not any breaking changes in core that would regress the plugin's behavior.

Make sure Travis runs these tests once they are ready.

Add documentation comments on public classes and functions, to make the codebase more accessible to contributors and plugin developers.

Overview

• Everything is a plugin
• Plugins can register other plugins (Angular plugin is a group of plugins)
• Context system keeps track of callbacks
• Use tapable
• Maybe have a distinction between an in-progress module and a fully analyzed module
  • We need to keep a lot of junk in memory that we can later throw away

Hooks

• initialize plugin
• filtering modules out from the list, before parsing each one
• ready to extract components from a module
• after components have been extracted from a module
• while visiting each component during dependency graph linking
• When ready to report

apply(analyzer) {
  analyzer.hooks.newModule.tap('MyPlugin', () => {});
}

TODO

• Setup hooks in the Analyzer class
• Have each Parser hook into an event

UI frameworks contain entities that are important to identify and track for dependency analysis. Hekla should recognize these entities and provide hooks for plugins to act on them.

Examples:

• Identify AngularJS entities (components, directives, factories, etc.)
• Identify React components
• Identify Backbone views and models

We should be able to run Hekla from an app maintained with create-react-app, where the build dependencies are hidden and inaccessible.

A possible way to handle this would be to run a build with stats (npm run build --stats) and then have Hekla run on the generated stats file, since it contains everything we need for analysis. It would not be as fast as integrating with Webpack at compile time, but this doesn't seem to be an option.

Having the full moduleName of a Module is useful, but it can create a lot of visual noise when creating visualizations of the analysis.

Add a shortName property to each Module, which is just the filename, unless it is named something like index.js or app.js, in which case it should add the parent directory to the shortName.

A few people have mentioned being interested in using Hekla for non-web languages (specifically Java, Kotlin, and C#), and Hekla needs a more modular way of adding grammars anyway. We still need support for CSS-family languages and this may be a good opportunity to add plugin support for totally custom grammars.

The current code owners plugin supports a data structure that doesn't match a convention like CODEOWNERS. We should make a new plugin specifically for the format, and reuse some of the logic to generate a similar tree.

We don't always want to see the workers running, if analysis is running on CI, or in tests. We should be able to opt into the output.

Can we extract the logic into a built-in plugin? Then we could use it in the CLI as well.

TODO:

• Update lerna
• Update other package dependencies
• Check in package-lock.json files? (What is best practice with lerna?)

We should be able to set metadata on the analysis, that is not specific to any specific module.

The finished analysis might look like this:

{
  "meta": {
    "title": "My Application", // Defined in `hekla.config.js`
    "unusedImports": [ // Created by an `UnusedImportsPlugin`
      "my-unused-module",
      "my-other-unused-module"
    ]
  },
  "modules": [
    // ...
  ]
}

TODO:

• CONTRIBUTING.md file
• Github issue/PR templates
• Code of conduct file

The project will be much easier to use and contribute to if it has type safety.

TODO:

• Update top-level readme file
• Update readme file for hekla-core
• Update readme file for hekla-cli
• Create readme file for hekla-webpack-plugin

It's common in UI code, especially older frameworks like Backbone and AngularJS, to include snippets of HTML that are compiled into templates. These template fragments have important logic that should be available for analysis, just like HTML files are.

Developers should be able to swap out the default babel parser for another one, like typescript.

• Move Analyzer and core logic from webpack plugin
• Delete older unused core
• Rename files/folders so everything is easier to find

We need some basic test coverage on the hekla-cli package so we know changes aren't causing regressions.

Things to test:

• Calling the CLI creates an analysis.json file
• Calling the CLI runs plugins that influence the analysis file
• Calling the CLI runs reporter plugins that create other files