En primer lugar, depende de lo que entienda por código "fuente original".

• Si quiere decir exactamente el mismo archivo en el mismo sistema de archivos que estaba editando cuando escribió el software, la respuesta es que no puede. Obviamente.

• Si te refieres a un código que es carácter por carácter idéntico al código que escribiste, es técnicamente posible pero poco probable en la práctica.

• Si se refiere a un código que funciona exactamente igual y "se ve casi igual", entonces sí, puede hacerlo. (Dependiendo de "principalmente".)

La respuesta también depende de la implementación de AST de la que esté hablando.

• Algunas implementaciones de AST no conservan los comentarios ni el espaciado o la sangría.

• Aparentemente, otras implementaciones de AST pueden conservar los comentarios; por ejemplo, como decoración en los nudos de los árboles.

• En teoría, es posible que una implementación de AST conserve absolutamente todo lo necesario para reconstruir un código fuente idéntico. (Pero no conozco un ejemplo que lo haga. Sería costoso en memoria y sin sentido).

¿Cuál es el daño en no poder recuperar los comentarios?

Bueno, depende de para qué quieras usar el código fuente regenerado. Si tiene la intención de poder reemplazar el código original, entonces hay problemas claros:

• Ha perdido (con suerte) los comentarios útiles que el programador incluyó para ayudar a las personas a comprender el código.

• Es común incrustar documentación API formal en forma de comentarios de código fuente estilizados que luego se extraen, formatean, etc. Si esos comentarios se pierden, se vuelve más difícil mantener la documentación API actualizada.

• Algunas herramientas de terceros usan comentarios estilizados para propósitos específicos. Por ejemplo, un comentario podría usarse para suprimir un falso positivo de un analizador de código estático; por ejemplo, un comentario # noqa en código Python suprime un error de estilo pep8 .

Por otro lado... este tipo de cosas pueden no ser relevantes para su caso de uso.

Ahora, a partir de las etiquetas, deduzco que está utilizando Shift-AST . A partir de un breve escaneo de la documentación y el código fuente, no creo que esto conserve ni los comentarios ni la sangría/espaciado.

Eso significa que no puede recuperar el código fuente que es carácter por carácter idéntico al código original. Si eso es lo que quieres... tu colega tiene 100% de razón.

Sin embargo, el código idéntico de carácter por carácter puede no ser necesario, por lo que esto puede no ser una limitación . Depende de su caso de uso.

Y podrías investigar Babel como alternativa. Al parecer, puede conservar los comentarios.

Un colega me dijo que AST no conserva el espacio y la sangría se perderá al convertir AST a código fuente. ¿Es la única razón?

Claramente, No. (Como explica mi respuesta).

No. Un árbol de sintaxis abstracta es abstracto en la forma en que abstrae la gramática ambigua, como los espacios en blanco y posiblemente también los comentarios (si son irrelevantes para el procesamiento posterior). Como normalmente no tiene sentido almacenar esta información, vale la pena eliminarla durante el análisis.

Si bien uno no puede volver al "código fuente original", aún puede volver a una representación equivalente que generalmente se denomina forma canónica .

Bueno, es posible. Si está utilizando shift-ast, puede hacerlo.

Paso 1:

 npm install shift-codegen

Paso 2:

 import codegen from "shift-codegen"; let programSource = codegen(/* Shift format AST */);

ProgramSource devolverá una cadena. Escríbalo en su archivo y use prettier para formatear su código.

Hay una alternativa a shift-ast llamada babel que brinda muchos beneficios, transformaciones y características de plantilla. También proporciona funciones de mecanografiado, flujo, jsx y comentarios y minificación.