Using async functions in replacer about putout HOT 6 CLOSED

Replacer is sync only because 🐊Putout can also be used as plugin for ESLint which works on IDE. Could you please provide more details, I don’t think that it will be a problem if you use sync versions resolve files paths. Also please tell me how do you want to run transformations, are you going to use 🐊Putout CLI for this purpose?

Also keep in mind that is better when your plugins is "clean" in this case is much simpler to write plugins using 🐊Putout Editor and also test them.

If you need to dial with FileSystem and you want test + write fast drafts in editor - use Scanner + Replacer. Take a look to nodejs/mjs-file for example.

Also take a look on RedPut to generate tests for your code mods and RedLint to run filesystem-based rules easily.

If you have any questions - ask, I’ll try to help.

from putout.

Hey @coderaiser thanks for the reply. I am using the module itself in JS, as an example it looks like:

// index.js
import putout from 'putout';
import * as convert from './plugins/convert.js'

// example of some code that would be loaded
let currentCode = `app.definitions[ 'app.view.context.entity.FilterMenu' ] = {

    extend : 'app.view.filter.FilterMenu',

    className : 'selectButton hasForm filter nonLinkList needsEntities',

    attributes : {
        'data-integration' : 'entity-filter'
    },

    intialize() {
        console.log('initialize');
    },

    loadData : function() {
        console.log('loadData');
    }
}`;

const code = putout(currentCode, {
    plugins: [
        ['modernise', convert],
    ],
});

I have a large legacy codebase that I want to convert from our custom module implementation to standard ES modules and classes.

So far I've found using the custom plugin has worked pretty well for this, but perhaps this is not the best way to implement it. If there is a more appropriate way I can look in to that, but using some async functions would be useful.

For now I have gotten around it by using some sync functions as you mentioned.

from putout.

How convert looks like right now? I don’t quit understand why you need async functions? What is final result of transformation?

If you provide more details I’ll suggest you best way to implement what you want.

Take a look at @putout/operator-match-files, here is usage example and way to run it programmatically. This is for cases when you need to dial with File System, and still have simple, easy testable code (with autogenerated tests).

from putout.

Hey @coderaiser sorry for taking a while to reply.
The code im converting has a custom loader that I'm trying to convert to standard module imports so for example one file might contain

requires: [
   'app.view.List'
]

and the file it requires has the following:

app.definitions[ 'app.view.List' ] = {
    ....
}

Im converting this so we end up with:

import AppViewList from 'FILE PATH HERE'

To do this I need to know the file path for app.view.List.

I was hoping to this asynchronously as there could be lots of files to resolve.
For now Im using child.execSync and a grep command which is reasonably fast but it would be useful if I could do this when the plugin runs async. My alternative is to generate a lookup of all the paths in advanced and use in my custom plugin, either way I am unblocked for now so I will close the issue.

Thanks for creating this library!

from putout.

So it something like this:

// App.js
requires: [
   'app.view.List'
];

// AppViewList.js
app.definitions[ 'app.view.List' ] = {
}

And you want:

// App.js
import AppViewList from './AppViewList.js';

// AppViewList.js
export default () = {
}

The idea is good, but we blocked by eslint/eslint#15394, (and this is really hard to support all IDE’s without ESLint, it should be made beforehand) when unblocked we can implement this, but there’s a couple things to remember anyways:

• Scanner was done to dial with file system API in a simplest possible way;
• If you dial with filesystem in another way, it will be hard to test things, you need lots of mocking, and it will not work in 🐊Putout Editor, so it’s preferred to write plugins as clean functions. You can write code in any way you like, of course, but this is preferred way that helps you to not shoot in your feet.

If you will have any questions related rules, I’ll be glad to help :).

from putout.

Here is how it can look like https://putout.cloudcmd.io/#/gist/9c145612c7f7f7fb6b8906c766346957/2a84c80ceec6e56e7d853d7ceb3e4ce5396443b6

The idea is: you traversing filesystem tree, received from redlint, and run regular 🐊Putout rule that does transformation you need. It is easy to test and develop, since there is no writing to file system, and when you are ready and tests passes you run on real file system.

from putout.