consider forking jscodeshift #67
Labels
💬 discussion
Ideas that need further discussion
Comments
|
Hey @kiprasmel 👋 Yeah I think forking it will be inevitable, however in the short-term, I'm trying to avoid the additional work while we lay the foundations for the project. Out of curiosity, what specific features are you thinking about adding to jscodeshift ? |
|
hey hey. i think i was experimenting with dependable codemods - i wanted to do some pre-processing first on all files (find all imports & exports), write some info out as json, then run a script to connect the info to make allow global awareness of what has been imported & re-exported, and only then use this in the actual codemod. and for that i think i had some difficulties and it seemed like forking jscodeshift would help, but not quite sure anymore. probably a bit out of date, but you can see my shenaningans in our repo's PR: https://github.com/pipedrive/CodeshiftCommunity/pull/6 i'll need to do more research on this one. |
|
Nice! No worries at all, thanks for sharing, I'll take a look 😀 When you say dependable codemods are you referring to codemods that can use dependencies from npm? Or codemods that depend on other codemods? The former is supported by this project 👍 |
|
sure, thanks. oh no, it's the latter. something similar to --sequential perhaps, but the purpose is different. i want to do some pre-processing with codemod A, write output to files, combine the output into 1 file to infer more knowledge, and then use that 1 file in another codemod. |
kiprasmel
added a commit
to kiprasmel/CodeshiftCommunity
that referenced
this issue
Jan 24, 2022
…Config depends on: hypermod-io#63 fixes a lot of cases for us: 1. we have a postcss codemod that we want to run, while still utilizing the @codeshift/cli. though, i don't know if these changes will work if we're using a remote package, will they? 2. we'll want to do some global pre-processing on files before running our codemod. though, there's still no way to provide the codemod as a __function__ instead of an __import path__ to jscodeshift, which will force us to do dependency injection instead of just passing the pre-processed results as an argument to a function. this is where the considerations to fork jscodeshift come into play again: - hypermod-io#67 Signed-off-by: Kipras Melnikovas <[email protected]>
kiprasmel
added a commit
to kiprasmel/CodeshiftCommunity
that referenced
this issue
Jan 24, 2022
…Config depends on: hypermod-io#63 fixes a lot of cases for us: 1. we have a postcss codemod that we want to run, while still utilizing the @codeshift/cli. though, i don't know if these changes will work if we're using a remote package, will they? 2. we'll want to do some global pre-processing on files before running our codemod. though, there's still no way to provide the codemod as a __function__ instead of an __import path__ to jscodeshift, which will force us to do dependency injection instead of just passing the pre-processed results as an argument to a function. this is where the considerations to fork jscodeshift come into play again: - hypermod-io#67 Signed-off-by: Kipras Melnikovas <[email protected]>
kiprasmel
added a commit
to kiprasmel/CodeshiftCommunity
that referenced
this issue
Jan 24, 2022
…Config depends on: - hypermod-io#63 fixes a lot of cases for us: 1. we have a postcss codemod that we want to run, while still utilizing the @codeshift/cli. though, i don't know if these changes will work if we're using a remote package, will they? 2. we'll want to do some global pre-processing on files before running our codemod. though, there's still no way to provide the codemod as a __function__ instead of an __import path__ to jscodeshift, which will force us to do dependency injection instead of just passing the pre-processed results as an argument to a function. this is where the considerations to fork jscodeshift come into play again: - hypermod-io#67 Signed-off-by: Kipras Melnikovas <[email protected]>
kiprasmel
added a commit
to kiprasmel/CodeshiftCommunity
that referenced
this issue
Jan 24, 2022
…Config depends on: - hypermod-io#63 example on how it could be used: - https://github.com/pipedrive/CodeshiftCommunity/pull/22 - though note we might refactor into separate PRs, idk, preferably would use directly from upstream (you). fixes a lot of cases for us: 1. we have a postcss codemod that we want to run, while still utilizing the @codeshift/cli. though, i don't know if these changes will work if we're using a remote package, will they? 2. we'll want to do some global pre-processing on files before running our codemod. though, there's still no way to provide the codemod as a __function__ instead of an __import path__ to jscodeshift, which will force us to do dependency injection instead of just passing the pre-processed results as an argument to a function. this is where the considerations to fork jscodeshift come into play again: - hypermod-io#67 Signed-off-by: Kipras Melnikovas <[email protected]>
kiprasmel
added a commit
to kiprasmel/CodeshiftCommunity
that referenced
this issue
Jan 26, 2022
…Config depends on: - hypermod-io#63 example on how it could be used: - https://github.com/pipedrive/CodeshiftCommunity/pull/22 - though note we might refactor into separate PRs, idk, preferably would use directly from upstream (you). fixes a lot of cases for us: 1. we have a postcss codemod that we want to run, while still utilizing the @codeshift/cli. though, i don't know if these changes will work if we're using a remote package, will they? 2. we'll want to do some global pre-processing on files before running our codemod. though, there's still no way to provide the codemod as a __function__ instead of an __import path__ to jscodeshift, which will force us to do dependency injection instead of just passing the pre-processed results as an argument to a function. this is where the considerations to fork jscodeshift come into play again: - hypermod-io#67 Signed-off-by: Kipras Melnikovas <[email protected]>
kiprasmel
added a commit
to kiprasmel/CodeshiftCommunity
that referenced
this issue
Jan 26, 2022
…Config depends on: - hypermod-io#63 example on how it could be used: - https://github.com/pipedrive/CodeshiftCommunity/pull/22 - though note we might refactor into separate PRs, idk, preferably would use directly from upstream (you). fixes a lot of cases for us: 1. we have a postcss codemod that we want to run, while still utilizing the @codeshift/cli. though, i don't know if these changes will work if we're using a remote package, will they? 2. we'll want to do some global pre-processing on files before running our codemod. though, there's still no way to provide the codemod as a __function__ instead of an __import path__ to jscodeshift, which will force us to do dependency injection instead of just passing the pre-processed results as an argument to a function. this is where the considerations to fork jscodeshift come into play again: - hypermod-io#67 Signed-off-by: Kipras Melnikovas <[email protected]>
kiprasmel
added a commit
to kiprasmel/CodeshiftCommunity
that referenced
this issue
Jan 26, 2022
…Config depends on: - hypermod-io#63 example on how it could be used: - https://github.com/pipedrive/CodeshiftCommunity/pull/22 - though note we might refactor into separate PRs, idk, preferably would use directly from upstream (you). fixes a lot of cases for us: 1. we have a postcss codemod that we want to run, while still utilizing the @codeshift/cli. though, i don't know if these changes will work if we're using a remote package, will they? 2. we'll want to do some global pre-processing on files before running our codemod. though, there's still no way to provide the codemod as a __function__ instead of an __import path__ to jscodeshift, which will force us to do dependency injection instead of just passing the pre-processed results as an argument to a function. this is where the considerations to fork jscodeshift come into play again: - hypermod-io#67 Signed-off-by: Kipras Melnikovas <[email protected]>
kiprasmel
added a commit
to kiprasmel/CodeshiftCommunity
that referenced
this issue
Jan 26, 2022
…Config depends on: - hypermod-io#63 example on how it could be used: - https://github.com/pipedrive/CodeshiftCommunity/pull/22 - though note we might refactor into separate PRs, idk, preferably would use directly from upstream (you). fixes a lot of cases for us: 1. we have a postcss codemod that we want to run, while still utilizing the @codeshift/cli. though, i don't know if these changes will work if we're using a remote package, will they? 2. we'll want to do some global pre-processing on files before running our codemod. though, there's still no way to provide the codemod as a __function__ instead of an __import path__ to jscodeshift, which will force us to do dependency injection instead of just passing the pre-processed results as an argument to a function. this is where the considerations to fork jscodeshift come into play again: - hypermod-io#67 Signed-off-by: Kipras Melnikovas <[email protected]>
kiprasmel
added a commit
to kiprasmel/CodeshiftCommunity
that referenced
this issue
Jan 26, 2022
…Config depends on: - hypermod-io#63 example on how it could be used: - https://github.com/pipedrive/CodeshiftCommunity/pull/22 - though note we might refactor into separate PRs, idk, preferably would use directly from upstream (you). fixes a lot of cases for us: 1. we have a postcss codemod that we want to run, while still utilizing the @codeshift/cli. though, i don't know if these changes will work if we're using a remote package, will they? 2. we'll want to do some global pre-processing on files before running our codemod. though, there's still no way to provide the codemod as a __function__ instead of an __import path__ to jscodeshift, which will force us to do dependency injection instead of just passing the pre-processed results as an argument to a function. this is where the considerations to fork jscodeshift come into play again: - hypermod-io#67 Signed-off-by: Kipras Melnikovas <[email protected]>
kiprasmel
added a commit
to kiprasmel/CodeshiftCommunity
that referenced
this issue
Jan 26, 2022
…Config depends on: - hypermod-io#63 example on how it could be used: - https://github.com/pipedrive/CodeshiftCommunity/pull/22 - though note we might refactor into separate PRs, idk, preferably would use directly from upstream (you). fixes a lot of cases for us: 1. we have a postcss codemod that we want to run, while still utilizing the @codeshift/cli. though, i don't know if these changes will work if we're using a remote package, will they? 2. we'll want to do some global pre-processing on files before running our codemod. though, there's still no way to provide the codemod as a __function__ instead of an __import path__ to jscodeshift, which will force us to do dependency injection instead of just passing the pre-processed results as an argument to a function. this is where the considerations to fork jscodeshift come into play again: - hypermod-io#67 Signed-off-by: Kipras Melnikovas <[email protected]>
kiprasmel
added a commit
to kiprasmel/CodeshiftCommunity
that referenced
this issue
Jan 26, 2022
…Config depends on: - hypermod-io#63 example on how it could be used: - https://github.com/pipedrive/CodeshiftCommunity/pull/22 - though note we might refactor into separate PRs, idk, preferably would use directly from upstream (you). fixes a lot of cases for us: 1. we have a postcss codemod that we want to run, while still utilizing the @codeshift/cli. though, i don't know if these changes will work if we're using a remote package, will they? 2. we'll want to do some global pre-processing on files before running our codemod. though, there's still no way to provide the codemod as a __function__ instead of an __import path__ to jscodeshift, which will force us to do dependency injection instead of just passing the pre-processed results as an argument to a function. this is where the considerations to fork jscodeshift come into play again: - hypermod-io#67 Signed-off-by: Kipras Melnikovas <[email protected]>
kiprasmel
added a commit
to kiprasmel/CodeshiftCommunity
that referenced
this issue
Jan 26, 2022
…Config depends on: - hypermod-io#63 example on how it could be used: - https://github.com/pipedrive/CodeshiftCommunity/pull/22 - though note we might refactor into separate PRs, idk, preferably would use directly from upstream (you). fixes a lot of cases for us: 1. we have a postcss codemod that we want to run, while still utilizing the @codeshift/cli. though, i don't know if these changes will work if we're using a remote package, will they? 2. we'll want to do some global pre-processing on files before running our codemod. though, there's still no way to provide the codemod as a __function__ instead of an __import path__ to jscodeshift, which will force us to do dependency injection instead of just passing the pre-processed results as an argument to a function. this is where the considerations to fork jscodeshift come into play again: - hypermod-io#67 Signed-off-by: Kipras Melnikovas <[email protected]>
kiprasmel
added a commit
to kiprasmel/CodeshiftCommunity
that referenced
this issue
Jan 26, 2022
…Config depends on: - hypermod-io#63 example on how it could be used: - https://github.com/pipedrive/CodeshiftCommunity/pull/22 - though note we might refactor into separate PRs, idk, preferably would use directly from upstream (you). fixes a lot of cases for us: 1. we have a postcss codemod that we want to run, while still utilizing the @codeshift/cli. though, i don't know if these changes will work if we're using a remote package, will they? 2. we'll want to do some global pre-processing on files before running our codemod. though, there's still no way to provide the codemod as a __function__ instead of an __import path__ to jscodeshift, which will force us to do dependency injection instead of just passing the pre-processed results as an argument to a function. this is where the considerations to fork jscodeshift come into play again: - hypermod-io#67 Signed-off-by: Kipras Melnikovas <[email protected]>
kiprasmel
added a commit
to kiprasmel/CodeshiftCommunity
that referenced
this issue
Jan 26, 2022
…Config depends on: - hypermod-io#63 example on how it could be used: - https://github.com/pipedrive/CodeshiftCommunity/pull/22 - though note we might refactor into separate PRs, idk, preferably would use directly from upstream (you). fixes a lot of cases for us: 1. we have a postcss codemod that we want to run, while still utilizing the @codeshift/cli. though, i don't know if these changes will work if we're using a remote package, will they? 2. we'll want to do some global pre-processing on files before running our codemod. though, there's still no way to provide the codemod as a __function__ instead of an __import path__ to jscodeshift, which will force us to do dependency injection instead of just passing the pre-processed results as an argument to a function. this is where the considerations to fork jscodeshift come into play again: - hypermod-io#67 Signed-off-by: Kipras Melnikovas <[email protected]>
kiprasmel
added a commit
to kiprasmel/CodeshiftCommunity
that referenced
this issue
Jan 26, 2022
…Config depends on: - hypermod-io#63 example on how it could be used: - https://github.com/pipedrive/CodeshiftCommunity/pull/22 - though note we might refactor into separate PRs, idk, preferably would use directly from upstream (you). fixes a lot of cases for us: 1. we have a postcss codemod that we want to run, while still utilizing the @codeshift/cli. though, i don't know if these changes will work if we're using a remote package, will they? 2. we'll want to do some global pre-processing on files before running our codemod. though, there's still no way to provide the codemod as a __function__ instead of an __import path__ to jscodeshift, which will force us to do dependency injection instead of just passing the pre-processed results as an argument to a function. this is where the considerations to fork jscodeshift come into play again: - hypermod-io#67 Signed-off-by: Kipras Melnikovas <[email protected]>
kiprasmel
added a commit
to kiprasmel/CodeshiftCommunity
that referenced
this issue
Jan 28, 2022
…Config depends on: - hypermod-io#63 example on how it could be used: - https://github.com/pipedrive/CodeshiftCommunity/pull/22 - though note we might refactor into separate PRs, idk, preferably would use directly from upstream (you). fixes a lot of cases for us: 1. we have a postcss codemod that we want to run, while still utilizing the @codeshift/cli. though, i don't know if these changes will work if we're using a remote package, will they? 2. we'll want to do some global pre-processing on files before running our codemod. though, there's still no way to provide the codemod as a __function__ instead of an __import path__ to jscodeshift, which will force us to do dependency injection instead of just passing the pre-processed results as an argument to a function. this is where the considerations to fork jscodeshift come into play again: - hypermod-io#67 Signed-off-by: Kipras Melnikovas <[email protected]>
kiprasmel
added a commit
to kiprasmel/CodeshiftCommunity
that referenced
this issue
Feb 10, 2022
…Config depends on: - hypermod-io#63 example on how it could be used: - https://github.com/pipedrive/CodeshiftCommunity/pull/22 - though note we might refactor into separate PRs, idk, preferably would use directly from upstream (you). fixes a lot of cases for us: 1. we have a postcss codemod that we want to run, while still utilizing the @codeshift/cli. though, i don't know if these changes will work if we're using a remote package, will they? 2. we'll want to do some global pre-processing on files before running our codemod. though, there's still no way to provide the codemod as a __function__ instead of an __import path__ to jscodeshift, which will force us to do dependency injection instead of just passing the pre-processed results as an argument to a function. this is where the considerations to fork jscodeshift come into play again: - hypermod-io#67 Signed-off-by: Kipras Melnikovas <[email protected]>
kiprasmel
added a commit
to kiprasmel/CodeshiftCommunity
that referenced
this issue
Feb 10, 2022
…Config depends on: - hypermod-io#63 example on how it could be used: - https://github.com/pipedrive/CodeshiftCommunity/pull/22 - though note we might refactor into separate PRs, idk, preferably would use directly from upstream (you). fixes a lot of cases for us: 1. we have a postcss codemod that we want to run, while still utilizing the @codeshift/cli. though, i don't know if these changes will work if we're using a remote package, will they? 2. we'll want to do some global pre-processing on files before running our codemod. though, there's still no way to provide the codemod as a __function__ instead of an __import path__ to jscodeshift, which will force us to do dependency injection instead of just passing the pre-processed results as an argument to a function. this is where the considerations to fork jscodeshift come into play again: - hypermod-io#67 Signed-off-by: Kipras Melnikovas <[email protected]>
kiprasmel
added a commit
to kiprasmel/CodeshiftCommunity
that referenced
this issue
Jul 8, 2022
…Config depends on: - hypermod-io#63 example on how it could be used: - https://github.com/pipedrive/CodeshiftCommunity/pull/22 - though note we might refactor into separate PRs, idk, preferably would use directly from upstream (you). fixes a lot of cases for us: 1. we have a postcss codemod that we want to run, while still utilizing the @codeshift/cli. though, i don't know if these changes will work if we're using a remote package, will they? 2. we'll want to do some global pre-processing on files before running our codemod. though, there's still no way to provide the codemod as a __function__ instead of an __import path__ to jscodeshift, which will force us to do dependency injection instead of just passing the pre-processed results as an argument to a function. this is where the considerations to fork jscodeshift come into play again: - hypermod-io#67 Signed-off-by: Kipras Melnikovas <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
at this point i'm reaching the boundaries of what can be done w/ this, without modifying the source code of jscodeshift itself.
it would be very benefitial to have a fork that we use directly.
i've done this a lot already - you fork the repository into your org, and add it here as a git submodule.
some build steps will need to be updated, but otherwise we'd be able to maintain our fork of jscodeshift, work out whatever behavior we want, and then even submit patches upstream (exactly what i'm doing now, but one level lower:D)
wdyt? myself need this a lot.
The text was updated successfully, but these errors were encountered: