fkling / astexplorer Goto Github PK

That way, the parser can be automatically selected when someone clicks on a shared link

Because Babel 6 uses a slightly different AST and plugin definition, I think it makes sense to add it as separate option (parser and transformer) instead of just upgrading Babel.

I am trying on http://astexplorer.net/#/ijSdoepnJz/1

Transformer doesn't work for some ES7 features like decorators. But parser works fine, as has option for it.

Simple example:

@decorator
class A {}

This cose cause to error in transformer:

Currently tools can only specify which parser to use (so it is selected by default) but not parser settings, which is required as well sometimes.

Apparently Facebook shuts down Parse.com http://bits.blogs.nytimes.com/2016/01/28/facebook-to-shut-down-parse-its-platform-for-mobile-developers/. IIUC, this affects us, and even though there is plenty of time for migration, decided to bring this up to attention rather sooner.

Not sure how we would show this or if we could make it look good but it would be useful (for me at least) to compare the AST tree between different parsers (in particular babel/esprima for babel-eslint). 😄

@fkling Would you be interested in putting astexplorer.net behind CloudFlare? Free plan should work perfectly, and will give HTTPS, HTTP/2 + SPDY and CDN out of the box which should speed up loading our bundles for users.

The toolbar is now so wide that parser information is not always shown properly on narrow screens. This is from a 13" screen:

Any suggestions for how/where to put this? Or should we simply break on white space?

Babel does not work well when minified.

This transform has an unexpected end of input: http://astexplorer.net/#/LTPfvqV0JE/13

Deleting line 3 or changing line 3 to a block comment will fix the transform and cause it to run though.

🏆

When you switch between languages, should the transform change automatically (ex: after switching from js/babel to html, the babel transform pane is still there). In the case of switching to html the pane stays on the screen even though the transform toggle is disabled.

For some reason, tree shows null values as "\"\"" which is somewhat confusing and makes think that it's a string containing two double-quotes.

Example: http://astexplorer.net/#/ijSdoepnJz/1 , cc @RReverser

http://astexplorer.net/#/0yIbDQg5KK

Input:

export default foo;

Transform:

j(file.source).find(j.ExportDeclaration).remove().toSource();

Output:

export default foo;

• babel-eslint
• espree
• acorn
• recast
• shift-ast

Would be nice to run the transform script twice, once on the original source, and then again on the transformed source. Then show a warning if the source changes on the second transform. If it does change that means it's probably not safe to run the script multiple times over the same codebase.

I've been thinking about how to best document jscodeshift and i think that having auto-complete/typeahead inside of astexplorer.net would be huge.

My biggest annoyance when writing codemods is that I want to create a node of type Something
but i don't know what arguments it takes.

Being able to do t.something(<list of arguments from ast-types>) would be great or, maybe at the bottom of the screen, when you select t.something, it shows the type definition.

Webpack (therefore UglifyJS) has problems minifying some files:

ERROR in app-6fe76ad4fb1070d5cdee.js from UglifyJs
Unexpected token punc «,», expected arrow «=>» [./~/codemirror/mode/javascript/javascript.js:363,0]

ERROR in 1-595b1745447d2e8d1d87.js from UglifyJs
Unexpected token punc «;», expected arrow «=>» [./~/codemirror/addon/tern/tern.js:324,0]

ERROR in 15-97b6ed0349ff4e6be2c6.js from UglifyJs
Unexpected token punc «;», expected arrow «=>» [./~/recast/lib/printer.js:196,0]

ERROR in 16-9ab0ec6c3bb5ef480ff7.js from UglifyJs
Unexpected token punc «)», expected arrow «=>» [./~/shift-parser/dist/pattern-acceptor.js:146,0]

ERROR in 18-4a8de760966ccf94578c.js from UglifyJs
Unexpected token punc «;», expected arrow «=>» [./~/babel-generator/lib/printer.js:79,0]

ERROR in 19-80325d20605b9cfcf9bf.js from UglifyJs
Unexpected token punc «;», expected arrow «=>» [./~/recast/lib/printer.js:196,0]

ERROR in 20-dc214efd0de9edbdb9bd.js from UglifyJs
Unexpected token punc «;», expected arrow «=>» [./~/typescript/lib/typescript.js:30938,0]

ERROR in 22-2661016f44c06a5eb7c6.js from UglifyJs
Unexpected token punc «)», expected arrow «=>» [./~/webidl2/lib/webidl2.js:234,0]

ERROR in 23-5b2dcb9b24f8a5691072.js from UglifyJs
Unexpected token punc «;», expected arrow «=>» [./~/escodegen/escodegen.js:907,0]

ERROR in 26-6d6700619899083ed12c.js from UglifyJs
Unexpected token punc «;», expected arrow «=>» [./~/esprima/esprima.js:2925,0]

We should configure webpack to add hashes to the bundle for cache breaking. To update index.html, we could use https://www.npmjs.com/package/html-webpack-plugin.

People reached out to be and showed interest in an embeddable version of astexplorer. This thread should explore how this would look like and what needs to be done.

I think there are two ways to achieve this and ideally we can support both:

1. Make astexplorer configurable via the URL so it can be embedded via an <iframe>.
2. Create a (more) reusable React component that can be used wherever React can be rendered.
3. ?

1. <iframe>

This should be fairly straightforward. The URL could contain UI options, such as the chosen parser, chosen transform, which visualization to show, whether switching parsers is allowed or not, etc. Basically just ways to configure how astexplorer looks like and optimize it a bit for smaller space (e.g. instead of side-by-side panes we could have tabs).

2. Dedicated React component

This probably requires bigger refactoring but could also be the most flexible solution since it could be used outside of browser environments (e.g. Electron apps). The component would be close to the main component in app.js but provide more configuration options. There some open questions:

• Should the toolbar be part of such a component?
• If yes, how would lazy loading the parsers work if we don't have any control over the build step?

Maybe the easier solution is to let the calling code pass the available parsers to the component. They would have to comply with our interface, but that shouldn't be too bad.

It would also be great if the calling code could add custom visualization / output panes (e.g. the transpiled code like in https://babeljs.io/repl/).

none of the buttons in the nav seems to be working...

The for…in loop in this example yields the following error.

TypeError: Cannot read property 'loc' of undefined(…)

Let the visitor write recast code to transform the AST. Maybe even animate the changes somehow? (e.g. step by step walk through).

Maybe we should have some shortcut to enable features. Like if you go to http://astexplorer.net/#postcss it will enable CSS and PostCSS.

... or something like that.

To make sharing code snippets easier, it would be convenient to store the selected parser and parser settings in the URL.

However, I don't really like to update the current URI with that information, since it will look ugly and mess with the browser history. Instead, we could add a "share" button that shows a copyable version of the URL, just like jsfiddle does.

I'm already working on this.

... and there is modified transformer code.

Tried to build & run locally, but got:

TypeError: $def is not a function in browser console in following context:

loadjs.d("323",function(require,module,exports){
// 19.1.3.1 Object.assign(target, source)
var $def = require('./$.def');

$def($def.S + $def.F, 'Object', {assign: require('./$.assign')});
},{"./$.assign":210,"./$.def":219});

loadjs.d("949",function(require,module,exports){

when i try to set a breakpoint in Devtools, it's either not set of jumps to a bad place in the source map. Is this something you're seeing as well?

P.S. Other than that, I really like the breakdown of the app. Really clean

I ran npm install and either npm run watch or npm run build and in another tab terminal I run npm start yet this is the contents of index.html:

<!DOCTYPE html>
<html>
  <head>
    <title>AST explorer</title>
    <meta charset="UTF-8">
    <meta name="description" content="An online AST explorer.">
    <script>
      window.webpackManifest = {%# o.manifest %}
    </script>
  </head>
  <body>
    <div id="page">
      <div id="container"></div>
      <div id="contribution">
        Built using
        <a href="http://facebook.github.io/react/">React</a>,
        <a href="http://babeljs.io/">Babel</a>,
        <a href="http://fortawesome.github.io/Font-Awesome/">Font Awesome</a>,
        <a href="https://parse.com">Parse.com</a>,
        <a href="http://codemirror.net/">CodeMirror</a>
        and
        <a href="https://webpack.github.io/">WebPack</a>
        |
        <a href="https://github.com/fkling/esprima_ast_explorer">GitHub</a>
      </div>
    </div>
  </body>
</html>

it looks like it's not modifying window.webpackManifest = {%# o.manifest %}

I'm on mac os with node v5.1.0 and npm 3.3.12
I'm also getting the same issue on node v4 too

I'm not able to reproduce this consistently though.

Hi,

Thanks for this amazing tool.

This transform is passing tests on my machine locally. But I get this error Cannot read property 'node' of undefined in astexplorer. This is my original repo and the transform is initializer-arity.

Sometime missing a semicolon at the end of statement seems to trigger similar kind of errors. Here is reproducable example And the semicolon is missing for the statement root.find(j.FunctionDeclaration, ...).....

Since it's not just Esprima anymore, maybe it's worth to rename the repo to make it less confusing? Github takes care of redirects after renamings, so it should be harmless.

Possible other parsers:

• https://github.com/marijnh/acorn

Also provide a way to change parsing options if available.

We could either encode the source code in the URL if it's short enough, or use something like Parse.com to store documents (or both!).

There are many more tools besides jscodeshift which could be added to the ast explorer for quick prototyping / testing. For example:

• eslint plugin development
• babel plugin development

To make adding new tools easy, some refactoring of the client side code and the DB schema is necessary. I already have a proof of concept commit locally but it still needs more tweaking.

The current idea/plan is that "tools" are React components which are rendered below the code editor and ast panel (just like the transform tool now) and which have access to

• The current parser
• The current code
• An API to highlight parts and show errors in the code editor

Tools would also be able to specify which parsers they work together with. They could render whatever interface they need.

If I include a jscodeshift.registerMethods in my transform, it works the first time, but if I change the transform, I get an error:

A method with name "findReturnsInCurrentScope" already exists.

I'd expect a fresh jscodeshift w/ no methods registered each iteration.

Repro: http://felix-kling.de/esprima_ast_explorer/#/NvHouJt2GJ

Just open it, and make a change to the transform.

This project is a nice playground for all those parsers. Thank you for making this!

I believe that for most people who stumble upon it, we are trying to find the best AST parser for our specific tasks.

And as far as the decision-making goes, your project is missing some key information that would simplify things for a researcher.

I understand you want your project to stay neutral about all the existing AST projects, but at least some basic statistics would have been really helpful:

• Performance charts
• Memory consumption charts
• Level of support for ES5, ES6, ES7
• Tree-Navigation features, performance

Not only this would be a great help to those who is trying to make the best pick among AST parsers, but also for the developers of AST projects to be able to see where their project has weaknesses.

Chrome, OS X

We should use CodeMirror's ability to highlight lines where errors occur.

For example, just write while(true); in the transform script and the whole browser will freeze when the code is run.

(practically I ran into this by introducing some accidental infinite recursion)

Instead of solving the halting problem, it would be cool if we just put a timeout on the transform and killed it after 30 seconds or so.

This lets you keep track of your snippets.

E.g. changing

export default function foo() {}

to

export function foo() {}

does not updated default: true to default: false (only after the toggling the node).