Extractor limitations

[monitz87]

I've noticed that the extractor regular expressions are fairly limited in what they can extract. For example, if I were to cut a javascript string in half because a line is too long, the extractor would only extract until the first half. For example:

mf('some_key', 'first half of a very long string' +
'second half of said string');

Only stores the first half in the database.

The same goes for expressions. If I do this:

const someValue = 'this is a string';
mf('some_key', someValue);

Then the extractor naturally treats it as if I didn't input a value at all and marks the string as removed. This is pretty much unavoidable unless you start evaluating the parsed code (which is maybe a bad idea), but it begs the question of why parse the files at all instead of simply using the arguments passed to the mf function to populate the database at runtime.

I know the advantage of the extractor over my runtime solution is that my solution requires the code to actually be run (templates rendered, events fired) in order to populate the string database, but it's a one time deal and not much of a hassle (especially considering that the extractor regular expressions do not cover all use cases, like block helpers in jade and interpolation parameters in javascript).

Cheers

[gadicc]

Thanks, @monitz87. You're right about the limitations of a regexp extractor, and indeed, processing at runtime is not a bad idea (aside from what you've already mentioned) - although it would need a lot of extra code to exchange the info from client to server and save it there.

In any event, the short of it is, I won't be working any more on the current version besides bug fixes, and for the next version, I'm most likely going to with a babel plugin which will indeed benefit from the parsed code :) (The next version will be a general npm release and not Meteor specific, and this is most likely the best approach to cover all our bases).

[monitz87]

That's awesome, I can't wait for the next version.