-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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(remix-dev/cli/migrate): fix convert-to-javascript
migration
#3987
fix(remix-dev/cli/migrate): fix convert-to-javascript
migration
#3987
Conversation
|
exportDefaultDeclaration: ExportDefaultDeclaration | ||
) => { | ||
/** | ||
* HACK: Can't use casts nor type guards in a `jscodeshift` transform |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to check if exportDefaultDeclaration.declaration
isn't of type DeclarationKind
(union), but there's unfortunately no other way than checking each possible union value separately, since we can't cast in a jscodeshift
transform.
We also can't extract this into a separate method, as than we would need a type guard, which is also not possible in a jscodeshift
transform.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this just to make TypeScript happy with this code or is it actually needed at runtime?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The whole hack is to make TS (actually jscodeshift
) happy 😢
Because I think the following is valid 🤔
// ClassDeclaration
export default class Foo {};
// FunctionDeclaration
export default function foo(){};
// =>
module.exports = class Foo {};
module.exports = function foo(){}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Found a way to convert these as well
isDefaultImport | ||
? j.memberExpression(callExpression, j.identifier("default")) | ||
: callExpression |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
import Foo from 'foo';
import * as Bar from 'bar';
// =>
const Foo = require('foo').default;
const Bar = require('bar');
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This won't always be correct 😬 I think we've made a big mistake by building this into our CLI. There are too many edge cases 😬
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This won't always be correct 😬
Can you give some examples where this won't be correct?
I'll try to add them.
I think we've made a big mistake by building this into our CLI.
We wanted to support JS & TS & (as you know) having this migration was the cleanest way of converting all files in a template/stack to JS.
Otherwise each stack had to do the conversion on its own.
I think the decision for doing it in our CLI was a good one, but it's a pain to think about every possible thing. 🙈
There are too many edge cases 😬
If only there was a package/library that could convert to ES5 without making the file a mess 🤔😅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do think that the TS->JS conversion is better suited as a standalone tool, in its own repo, provided as-is without covering all edge cases, rather than being included in our migrations in our CLI. I've mentioned this before and feel even more strongly about it now.
I think "migrations" concept in our CLI should be reserved for helping automate upgrading through breaking changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That said, we currently offer the --no-typescript
option during create... so we'd have to deprecate / remove that option to get out of the business of doing the TS->JS conversion. Which I'd be in favor of, but its a breaking change for the CLI.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We supported both JS & TS version of our templates/stacks from v1.0.0, so that's why I added the new convert-to-javascript
migration.
Now that we come across these extra changes that need to be made, I can see a separate package working for stacks.
We would still have the "problem" that our templates will need to use it as well.
We could definitely stop officially supporting JS, but that would indeed be a breaking change, so needs to wait for v2.
If we want, we can already create a separate package that's solely responsible for the JS conversion (or we could put it in a scripts
package if that's preferred) & let the CLI use this new package.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do like the idea of moving this all to a separate package so it can be quickly iterated upon and remix can depend on that package until v2 when it can be removed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kentcdodds Do you mean a separate Remix package or like a separate personal package?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably a separate Remix package I think. But anyway, I think we should probably just merge this and move forward.
3c723de
to
699279f
Compare
699279f
to
11b2012
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your work on this 👍
Forgot to add a changeset. Added here: 3696554 |
@MichaelDeBoey Looks like this PR failed our checks on Windows, so we probably should have held off on merging. @mcansh is looking into it, but @MichaelDeBoey if you have any instincts as to why (since you wrote the code), let me know! |
it doesn't appear to be a timeout, it's set to 20s but we're failing at around 9.5s this is the stack trace:
|
Then it's strange, as I don't do anything that can't be done on Windows I think 🤔 The error seems to be about creating a ? j.functionExpression.from(exportDefaultDeclaration.declaration) |
yeah it's weird, macOS has no troubles with it, but ast-types throws on Windows when comparing it's internal type as it has the "built" type as |
@mcansh That's really weird 🤔😅 I'll resubmit this PR with this |
This will partially resolve remix-run/indie-stack#134