-
Notifications
You must be signed in to change notification settings - Fork 334
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Define a new node type as a chunk of code to output verbatim #73
Comments
I think we can handle it by parsing it by Esprima and injecting produced AST to given tree before passing AST to Escodegen, right? @michaelficarra: |
I would prefer to don't have a dependency on Esprima (or any other Javascript parser). I chose Escodegen in the first place because it focuses on doing just one thing :) The solution I'm using right now is to convert those chunks to |
@Constellation: CoffeeScriptRedux does what @drslump describes. That feature of CoffeeScript is highly discouraged, so we don't worry about the performance costs. The method you describe (parsing it with Esprima) was considered a few times, but we would rather avoid that dependency and just produce an |
I see. It's reasonable decision. @drslump: If we introduce CodeExpression specially, we must throw this benefit. Modules cannot analyze CodeExpression because of lack of structure. So I would prefer these ways, parsing it by Esprima or transforming it to eval call. |
@Constellation: I think that's a good decision. Let the consumers of escodegen add esprima as a dependency if that's the functionality they need. |
Unfortunately I cannot easily include Esprima since my compiler runs on .Net, executing escodegen with a Javascript interpreter, which is not the fastest thing on earth, while I work on a native code generation implementation. I understand your concerns but to IMHO using a code generation library means I should be given as much control as possible about what to place in the output. Even if the resulting AST would not be interoperable with other tools, I might choose to generate one version of the AST for escodegen and a standard one using calls to eval. Instead of defining a new node type, expression node types could support an annotation (similarly to how comments are being implemented right now), which would tell escodegen to use the code string defined there instead of traversing the node.
When traversing the AST, if the node contains an |
@drslump: How about using the |
@michaelficarra: +1 |
Now Escodegen checks |
Since it seems that
|
Nice concept. And I would prefer to pass special name with option, like this, escodegen.generate(AST, { verbatim: 'x-replace' }) And we should note, if verbatim option is used, we cannot ensure result code is valid JavaScript and modules treating Mozilla AST may not recognize this(for example, Esmangle will be broken when this option is used). |
In the meantime, we enable verbatim of Expression. So indentation is not considered. |
Thanks, I've merged. |
Currently I don't see any way to pass a chunk of code to be outputted just as is in the generated source. The use case is when generating an AST from a language that allows to define chunks of code to be placed verbatim in the generated javascript, much like CoffeeScript's backtick notation.
It could work something like this:
The generator would output the contents of the code with only the following processing performed:
Since it's impossible to know the precedence order of that node, it should always be assumed that it's very low (Assignment), wrapping it with parens if used in a binary or member expression for example.
The text was updated successfully, but these errors were encountered: