Can jscodeshift output to a different file?

I’m building a library that creates model classes backed by Immutable.js data structures based on Flow type definitions. I would prefer my jscodeshift transform to read the Flow definition in one file but output the transformed file in a different location, but I don’t see that as being supported by jscodeshift. It seems to only be set up to overwrite files it processes (which is obviously the common use case). Could anybody let me know if this is possible or if you’d suggest an alternate approach? Here’s an example of what I’m trying to build:

model_defs/user.js

export type UserType {
  id: number,
  name: string,
};

The jscodeshift transform would process this file and output something like:

models/user.js

export class User {
  _state: Immutable.Map();

  constructor(

  get id(): string {
    return this._state.get('id');
  }

  setId(id: number): User {
    return new User(this._state.set('id', id));
  }

  get name(): string {
    return this._state.get('name');
  }

  setId(name: string): User {
    return new User(this._state.set('name', name));
  }
}

I have this transform working, but it currently overwrites the definition file. I’ve thought about copying all the matching files into a temp directory, processing those and then moving them to their final destination, but that approach seems more difficult than I’d like. I’ve also thought about creating my own runner that runs each file through the jscodeshift API - maybe using a dry run - and writes the desired file based on the string results of the transform. This is less than ideal as I’d be copying many aspects of the jscodeshift runner and I’m not sure yet if I can easily access the string results, but I think I will be able to.

I’m trying to take this approach so that the resulting class files are not stored in source control, but generated based solely on the type definitions. As a last resort, I could probably drop that desire in favor of overwriting previously transformed files. But I feel this approach is more confusing and prone to producing unexpected results.

Thanks for reading this long post. I’d love to hear suggestions on how best to approach this.

[ElonVolo]

In my evcodeshift fork of jscodeshift, I added the ability to pass an option to defineTest that create a folder in the project directory that contains all the transforms that are made during the unit tests. I had trouble with figuring out what transforms were going bad during unit tests, and the diffed output wasn’t very helped, so I added in the options to save output from unit tests. See the below link for documentation on it.

(I probably need to put it in the README at some point (thought I think the general documentation on what to pass in for test options was kind of sparse).

https://github.com/ElonVolo/evcodeshift/blob/main/sample/__tests__/reverse-identifiers-test.js

But at this point, my understanding from the Facebook people is that they’re not going to be adding any additional features to jscodeshift (I already tried adding a --gitignore flag to use the projects .gitignore to avoid transforms), so work on jscodeshift is pretty much going to be limited to bugfixes. I’m guessing that a new flag isn’t going to fly with them (pun intended).

[TSMMark]

@danielo515 Maybe you can create multiple instances of the root, such as:

  const rootA = j(fileInfo.source)
  const rootB = j('')

Then remove nodes from rootA, and add them to rootB Then writeFile rootB.toSource such as @dbchristopher suggested https://github.com/facebook/jscodeshift/issues/160#issuecomment-823541122