gilbsgilbs/babel-plugin-i18next-extract

Allow specifying fallback-functions to parse AST-node for extractors

Jaskaranbir opened this issue · 0 comments

Is your feature request related to a problem? Please describe.

Having an interpolated string (using template-literals) causes failure in processing the Node. This is currently handled by throwing an error; example:

throw new ExtractionError(
`Couldn't evaluate i18next key. You should either make the key ` +
`evaluable or skip the line using a skip comment (/* ` +
`${COMMENT_HINTS_KEYWORDS.DISABLE.LINE} */ or /* ` +
`${COMMENT_HINTS_KEYWORDS.DISABLE.NEXT_LINE} */).`,
path,
);

However, it would be helpful to just get the string as whole without substituting the variable for its value. For example, this string would cause failure: some interpolated string ${someVar}. But instead, this could just be output as is (some interpolated string ${someVar}), without attempting to substitute someVar for its value, and not throw an error.

Describe the solution you'd like

The loader-config should accept a fallback callback-function to allow custom-processing the AST. In my case, I could get the actual string I need by just replacing above error-code with:

const path = args[0];
keyEvaluation = path.hub.file.code.substring(path.node.start + 1, path.node.end + 1);

The implementation can look something similar to:

if (typeof keyEvaluation !== 'string') {
    if (config.fallbackTCallBabelNodeProcessor) {
        keyEvaluation = config.fallbackTCallBabelNodeProcessor(args[0]);
    }
    else {
        throw new ExtractionError(
          `Couldn't evaluate i18next key. You should either make the key ` +
            `evaluable or skip the line using a skip comment (/* ` +
            `${COMMENT_HINTS_KEYWORDS.DISABLE.LINE} */ or /* ` +
            `${COMMENT_HINTS_KEYWORDS.DISABLE.NEXT_LINE} */).`,
          path,
        );
    }
}

This will add a lot of flexibility to the plugin.

Describe alternatives you've considered

An alternative is to actually implement this kind of fallback inside evaluateIfConfident, where it just returns the code as is. In my case, replacing null on last line of this function with return path.hub.file.code.substring(path.node.start + 1, path.node.end + 1); does the trick.


I am open to taking this on and creating a PR if the solution looks viable.