Less restrictive parsing

[coderaiser]

Describe the feature

Would be great to have ability to parse some declarations in any context.

allowImportExportEverywhere: By default, import and export declarations can only appear at a program's top level. Setting this option to true allows them anywhere where a statement is allowed.

allowAwaitOutsideFunction: By default, await use is only allowed inside of an async function or, when the topLevelAwait plugin is enabled, in the top-level scope of modules. Set this to true to also accept it in the top-level scope of scripts. This option is discouraged in favor of topLevelAwait plugin.

allowReturnOutsideFunction: By default, a return statement at the top level raises an error. Set this to true to accept such code.

(c) Babel

Right now I see:

 × Return statement is not allowed here
   ╭────
 1 │ return undefined
   · ────────────────
   ╰────


Caused by:
    0: error was recoverable, but proceeding would result in wrong codegen
    1: Syntax Error
    at Compiler.parseSync (/Users/coderaiser/putout/node_modules/@swc/core/index.js:74:36)

Babel plugin or link to the feature description

https://babeljs.io/docs/en/babel-parser#docsNav

Additional context

This is very useful for 🐊Putout code transformer, since it uses pattern based search using 🦎PutoutScript.

Also I'm working on swc-to-babel which will help to use Babel tooling with AST received from SWC.

[kdy1]

FYI, swc to bqbel is already implemented using rust code

[coderaiser]

@kdy1 could you please tell me how can I use it from JavaScript?

[kdy1]

You would have to add an api to @swc/core or create a node binding

[coderaiser]

Let's add an api to @swc/core, that would be awesome :)!

[kwonoj]

I'm curious about general usecase for this feature : do we know context when / why babel introduced this? Most of options sounds like edgy case handling that won't be needed in general parse processing.

[coderaiser]

@kwonoj I’ll tell you about the context. Here is the plugin for 🐊Putout that adds await when you return promise:

export const replace = ({
    ‘return __a’: ‘return await __a’
});

Both constructions on the left side and on the right side are parser to AST.

Such thing is impossible with SWC right now.

Also with Babel Template you can create a node, and put it where you needed.

[kwonoj]

My question for context is, historical context why babel have those options. I do understand this request itself's reasoning.

The reason I'm asking context is how common is this case for the parser that demands swc's core need to expose this as public interface, other than usecase of putout in the request.

In ohter words, I'm bit afraid once we exposed this as core's public interface and there are very few users will need this, namely putout / and possibly few others. Do we have other context this is required in common for general parser processing?

[coderaiser]

Any AST processing, when you parse code to a node, not the whole file.

[coderaiser]

@kdy1 Any progress on this? It would be useful for any type of code transformations.

[kwonoj]

We don't have any immediate plan / priority to support this. If there's an update, we'll update issue otherwise it means there's no specific updates.