deprecate/metal-soy-critic

A metal-soy code validation utility.

metal-soy-critic

Note: the metal-soy-critic project has been moved to the metal-tools-soy repo.

To simplify development and maintenance and handle all tools-soy projects, this project has been moved to the metal-soy-critic under the umbrella of the metal-tools-soy monorepo.

metal-soy-critic's Issues

These params can't be found in STATE or your Class:

If I have class A, that extends class B, and the soy template for A implements STATE params from B it will show the following error.

These params can't be found in STATE or your Class:

The parent class needs to be resolved and parsed as well. Obviously that makes things a lot more complicated :)

Fails to throw an error when no namespace is declared in a soy file that does not have a corresponding js file.

1. Create a soy file without a namespace declaration.

/**
 * LinkSpan
 */
{template .render}
	{@param attributes: attributes}
	{@param? content: html|string}
	{@param? span: bool}

	{if $span}
		<span {$attributes}>{$content}</span>
	{else}
		<a {$attributes}>{$content}</a>
	{/if}
{/template}

2. Do not create a js file.
3. Run mcritic.

Expected result: MCritic throws an error declaring that you have not written valid soy.

Actual result: MCritic does not throw an error.

Allow for a metal-soy-critic config file.

We have a few cases where configuration makes sense for metal-soy-critic. One use case is allowing for a custom regex when determining the matching import path for a component having it's render template called.

Let's go with a config file like .soycriticrc or soycritic.config.js. The CLI can recursively look in parent directories for this file, and read it's configuration when one is found.

/cc @jbalsas

Feedback for parsed files that have no issues

Hey guys, awesome idea for a tool!

The first time I ran it on a file, it didn't find any issues so there was no output. This made me think it was potentially a bug, and I wasn't sure if it actually read the file or not.

It might be nice to have output that lists all files that pass your checks, similar to test output which lists both the tests that pass and the ones that fail. Maybe something like...

The following 1 file(s) passed all checks:

File - src/SomeFile.soy

Recursive configuration

Currently, mcritic stops at the first occurrence of a config file. This makes it impossible to override default settings in specific areas of the code. Given the following layout:

• root
  • .soycriticrc.json
  • src
  • test
    • .soycriticrc.json

Soy files within the test folder will be linted using the root configuration rather than by the mix of both.

Multiple soyToImport configs

Currently, we support just one pair

  "callToImportRegex": "(\\S+)",
  "callToImportReplace": "{$1|param}"

This can be problematic if different types of imports are mixed in the same project, making it really hard to adapt. We could try to

Have synced arrays

callToImportRegex: string|array<string>
callToImportReplace: string|array<string>

Or move this directly to an array of regex,replace pairs

callToImport: [
    {
        regex: /regex1/,
        replace: 'replace1'
    }, {
        regex: /regex2/,
        replace: 'replace2'
    }
]

I'm not sure if anyone other than us is using the old syntax. The new one feels more robust. We could try to deprecate the old one, or just break it and release a major change if we don't care about maintaining that.

Thoughts, @Robert-Frampton, @mthadley?

Missing import imcompatible with unused variable

We are currently looking for imports in a componente when a template is used, so if you're using {call Dropdown.render} we're looking (I guess ) for an import Dropdown from... statement.

If not found, we have get the following message:

File - src/main/resources/META-INF/resources/components/configurabledropdown/ConfigurableDropdown.soy

     It looks like the following component calls are missing an import:
     
     Dropdown

This is incompatible with estlint::unused-var rule, so we usually have

import metal-dropdown // avoid declaring Dropdown when not used

Allow for use as a Library.

We should export some functions that allows using metal-soy-critic as a library. We will probably need to update some of the return types so that they make sense for more generic use cases.

We can also consider adding a JSON output option. This would be useful for integration with tools like linters, continuous integration, etc.