Closed vikaspotluri123 closed 5 years ago
Hello, I'd like to try this. I'm really comfortable with es6 syntax and I think I could use this to get more familiar with the code base.
Could you please help me with what you are looking for exactly?
Hey @karaggeorge π I was planning on migrating the entire Ghost repo (so specifically TryGhost/Ghost) after I get done with my semester, but I'm definitely not opposed to getting help π
@kirrg001 how would you suggest multiple people working on the same thing? I was thinking @karaggeorge PRs into my repo and enables allow edits from maintainers
so I can push commits as well π€
Babel won't be used since that will add additional dependencies; the plan is to merge the migrations after v4 is deprecated (April 30)
Thanks for interest and help π
Multiple people is fine, but please only very small pull requests - 1-2 files per PR. Otherwise this can heavily conflict with existing pull requests and takes too much time to review. It also means, if multiple people would like to help, this needs communication here, who takes over which folder. And please do not rewrite logic, only ES6 style changes π
If you want to rewrite logic, please argue in this issue and wait for confirmation. After confirmation, you can submit this rewrite as separate PR.
e.g. changing _.includes(array) -> array.includes
is absolutely fine and does not need confirmation
e.g. rewriting a whole function needs confirmation
Please do after we've dropped Node v4 ππ»
Should the entire project be migrated? Or just a specific part (server?).
Only the server and test folder.
Is babel used?
No
@vikaspotluri123 @kirrg001
Please do after we've dropped Node v4 ππ»
Do you mean, start working on it after Node v4 is deprecated? Or it's ok to create PRs now, but they won't get merged until it's deprecated?
Sounds good. I'm planning on working on it now (in the next few days) so it shouldn't cause conflicts. I'll keep every PR small 1-2 files.
Sounds good. I'm planning on working on it now (in the next few days) so it shouldn't cause conflicts. I'll keep every PR small 1-2 files.
This sounds good - can you let me know what folder you plan on migrating first? I know I probably won't have time right now to work on it, but if I somehow find it, I don't want to be stepping on your toes π
I'll start with core/server/api/
π
Do you mean, start working on it after Node v4 is deprecated?
After Ghost has dropped it.
Checklist:
If anyone knows of a way to make it less obtrusive, that would be great π
@vikaspotluri123
I guess I'll wait until Ghost drops it before working on this π
Yeah please wait 2 weeks minimum, because of the Node v4 drop and we will merge dynamic routing in a 1-2 weeks, which moves some files around. It's quite a big feature. I'll give the go here if you want :)
@kirrg001 sounds good!
FYI: We also have a couple of dependencies, which would need an ES6 update. I am not sure how much ES6 updates are required, but worth double checking.
e.g.
Let me know if you are interested in helping out there as well π€
Regarding the ES6 updates in Ghost. Dynamic routing was not merged yet and i would love to wait with the ES6 updates till then. As said, i'll let you know, when you can start with ES6 PR's for Ghost.
I'd like to try this too :). It's likely done file by file but how can we prevent same modification from happening? Can we break it down to many small issues each have its own PR later? Once an item is picked from @vikaspotluri123 list, for example, it'll be crossed out and added an issue number so others can simply ignore it.
@Tiendq you're on the right track wrt the plan - whenever someone starts working on something, they will post it as a comment here, and I will update the master list w/ WIP by {username}
. The person will create PR(s) which update files to support es6; the number of PRs per item is variable based on file length and file complexity. Finally, when all of the files are updated / migrated, I will update the master list by removing the WIP label and checking it.
As far as I know, maintainers can also edit my list so if I don't get around to it, someone hopefully will.
Right now, as @kirrg001 we're holding off on starting since the Ghost Team wants to merge dynamic routing first.
I'd like to help. I realize we have to wait until the dynamic routing is merged in, but if there's anything I can do before then, please let me know.
I would like to be involved in this as well.
I'd be glad to work on this too. Subscribing to a thread to not miss the updates.
Sorry. I was three weeks off. As soon as https://github.com/TryGhost/Ghost/pull/9596 get's merged, you can start with the ES6 migrations. Thanks :)
currently working on this as well.
Have a pull request in on ./helpers/asset.js
Will start working on the smaller files in this folder when I have time.
@hkd987 I've updated the checklist and marked you as working on helpers/*
If no one picked it, I could start with controllers
or apps
tomorrow :)
@tiendq starting is still on hold for now; see #9662 (comment)
However, I've marked you as working on the controllers folder
https://github.com/TryGhost/Ghost/pull/9596 was merged π
@vikaspotluri123 controllers
has been disappeared :D, so I'd like to give another try with apps
:)
Hi @vikaspotluri123 I would like to help with this. Let me know which directory I can pick up. Thanks!
@mandeepm91 Feel free to pick any folder that isn't checked off and does not have WIP to the right of it!
Before you raise a PR, ensure you have read this conversation about arrow functions. Feel free to add your opinion.
FYI, for anyone working on this there are numerous codemods available to automate a lot of the es6 transformation work. This article is a nice introduction to codemods https://medium.com/airbnb-engineering/turbocharged-javascript-refactoring-with-codemods-b0cae8b326b9
@vikaspotluri123 I'll start with the api
folder
@kirrg001 @kevinansfield I see many named callback functions, and function names are not used anywhere. Obviously I will replace them with arrow functions but I'm not sure if it's right decision :)
@vikaspotluri123 it's my first contribution so if I am making any mistakes in following the process, please let me know. Thanks
@vikaspotluri123 @kirrg001 @kevinansfield
The linter is showing some issues which aren't really issues in my opinion. For example, consider the code:
.then(() => _private.readRedirectsFile());
It raises the issue that _private.readRedirectsFile()
should be inside a block. So, consequently I am changing this to:
.then(() => { return _private.readRedirectsFile(); });
But I think the former approach is more concise and more readable. What do you think ?
@kirrg001 Sorry I missed your comment regarding including small PRs with only 1 or 2 files in a PR. I was earlier planning on converting the entire core/server/api
directory and then raising a PR. I have already converted 12 files so far. Will it be ok if I raise a PR for those 12 files?
@mandeepm91 Agree, linter is strict more than necessary in certain situations. I have also noticed another case: .then((result) => ...)
, parentheses are must while .then(result => ...)
is fine.
wrt linting... @kirrg001 is there any plan to use the Ghost eslint plugin for this repo? If so, we might be able to add another npm / grunt script (i.e lint:bleeding
) which uses an eslintrc file based on the plugin. Then, for PRs related to ES6, there would be an additional requirement that yarn lint:bleeding
passes which would allow for the gradual migration to the new rules π€
I also would like to help you out, can I still refer to the checklist posted by @vikaspotluri123 as a reference to what still need to be done?
Yep, @Huc91! I think I've notated all the PRs, but the assignments are up to date. @ everyone else - if a PR doesn't get added to the list after a day or two feel free to ask me to add it π
As mentioned in #9689 (comment), @billfienberg is working on the adapters
folder
@vikaspotluri123 Thanks, I'm gonna take a look
@vikaspotluri123 I am working on everything inside server/web. More to come
web/middleware/static-theme.js
=> do we want to get rid of _.inlcudes?
web/middleware/url-redirects.js => Line8: Can we use Object destructuring? => Line25: Can we use JS shorthand property names? (ES5)
These cases are not part of the initial es6 migration 'guide', so I want to confirm before making these changes.
@larsnolden I've marked you as working on web π
All 3 of your questions have been discussed in other issues, and the final decision was "It's fine", so go ahead! π
You can automate the ES6 migration using https://github.com/esnext/esnext. I have recently used it just to try it out and it worked okay. I think the module is definitely not compatible with everything, but wanted to share if somebody wants to try it out π€
Sorry about that long list of commit messages. My old branch got messed up while syncing my fork with the upstream. I have kept that old branch aside for now and created a new one. I will be creating small PRs with 2 files in each PR from now onwards
I'm new but it would be super easy to use TypeScript to access ES6+ features even if you didn't type anything, though, that's always a great idea. I'd be happy to refactor to TS or help with the ES6+ refactor. It would also be great to use named exports with destructured imports. This helps a lot with future contributors because of auto-complete. Also, would classes be on this list instead of prototypes?
(named exports instead of default exports are better, IMO. With defaults, someone could:
import Something from './something';
import something from './something';
Update: API folders are now being updated by Ghost team.
Update: /web
folder being worked on by Ghost team :tada:
s the migration complete? The checkboxes seem outdated...
I think with the exception of API everything should be up to date π€
It's not finished. e.g. the data/
folder was not transformed into ES6.
I will hop on and contribute to this too
This is something ~I plan on working on in the middle of May~ a bunch of people are helping out on! π
var
->let
/const
_.includes(array)
->array.includes
(dropping v4 support at the end of April makes this possible)_.each(array)
-> array.forEach_.isArray(array)
->Array.isArray(array)
- Only if it removes the necessity of requiring lodash in a specific file_.isEmpty(array)
->array.length === 0
(or!array.length
)var self = this
(arrow functions instead)(a = 2, b = 2) => a + b
)Checklist: