Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix standalone transform runs - resolve path of transform #63

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

kiprasmel
Copy link
Contributor

@kiprasmel kiprasmel commented Oct 29, 2021

in the issue you linked [1] from jscodeshift, i think you forgot the path.resolve for non-http(s) imports (not even sure how they'd work tbh).

i tried running a local transform and it didn't work, but with this fix it did regardless of where i called the packages/cli/bin/codeshift-cli.js from. i think you might've been using the packages and not the --transforms flag so i understand why you could've missed it 😅

tbh there are more improvements to make w/ the local transforms (see [2] & I'll create more later) but this is the first step :D

seen here:
https://github.com/facebook/jscodeshift/blob/aea20523d9d616e7debc7bc00b66835284278555/bin/jscodeshift.js#L142

[1] facebook/jscodeshift#398
[2] #48 (comment)

@kiprasmel kiprasmel closed this Oct 29, 2021
@kiprasmel kiprasmel deleted the patch-1 branch October 29, 2021 23:18
@kiprasmel kiprasmel restored the patch-1 branch October 29, 2021 23:18
@kiprasmel kiprasmel reopened this Oct 29, 2021
@danieldelcore
Copy link
Contributor

This is fantastic mate! Thanks so much for contributing 🤙
Could you please run yarn changeset and follow the prompts to make sure the CLI gets versioned?
A patch should do :)

@danieldelcore
Copy link
Contributor

Also looks like there are some tests that need to be updated 🙏

@kiprasmel
Copy link
Contributor Author

kiprasmel commented Nov 1, 2021

Thank you c:

Could you please run yarn changeset and follow the prompts to make sure the CLI gets versioned?

Will try tmr.

A patch should do :)

Pretty sure this would be a breaking change since it will make broken behavior no longer broken but i assume nobody was using it so should be fine lol

Also looks like there are some tests that need to be updated 🙏

uh oh, seems that they are marking the now-correct behavior as wrong? not sure if i have the time to dig into them tbh, any chance you could take a look?

also, should we consider the https? imports, as mentioned in [1]?

  /^https?/.test(options.transform) ? options.transform : path.resolve(options.transform),

@danieldelcore
Copy link
Contributor

Can do, I'll have a look at this asap!

@kiprasmel
Copy link
Contributor Author

in addition to this, i stopped using require.resolve in the codeshift.config.js.

kiprasmel added a commit to kiprasmel/CodeshiftCommunity that referenced this pull request 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 pull request 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 pull request 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 pull request 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 pull request 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 pull request 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 pull request 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 pull request 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 pull request 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 pull request 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 pull request 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 pull request 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 pull request 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 pull request 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 pull request 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 pull request 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 pull request 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 pull request 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
Copy link
Contributor Author

fyi @danieldelcore i've rebased again (same w/ #97 which depends on this). i see you removed the path import so i had to re-add it again hehe

@kiprasmel
Copy link
Contributor Author

hey @danieldelcore - any updates on this? this is a prerequisite for #97 which would help get rid of our fork!

i can solve the merge conflicts but that's less relevant -- main question is - how do i fix the tests not passing, and what else should i do to get it merged? thanks!

in the issue you linked [1] from jscodeshift, i think you forgot the `path.resolve` for non-http(s) imports (not even sure how they'd work tbh).

i tried running a local transform and it didn't work, but with this fix it did regardless of where i called the `packages/cli/bin/codeshift-cli.js` from. i think you might've been using the packages and not the --transforms flag so i understand why you could've missed it 😅

tbh there are more improvements to make w/ the local transforms (see [2]) but this is the first step :D

[1] facebook/jscodeshift#398
[2] hypermod-io#48 (comment)

Signed-off-by: Kipras Melnikovas <[email protected]>
kiprasmel added a commit to kiprasmel/CodeshiftCommunity that referenced this pull request 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]>
@danieldelcore danieldelcore force-pushed the main branch 2 times, most recently from facba25 to 5248c0e Compare July 15, 2024 01:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants