-
Notifications
You must be signed in to change notification settings - Fork 1
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
Use Yarn with Rosetta 2.0? #283
Comments
If we do use Yarn, should we use version 1 or version 2? |
Re V1 vs. V2, according to the Yarn docs, you don't have to use the new "Zero Install"/"Plug'n'Play" scheme that gets rid of |
Yes, one repo sounds good. How does this relate to yarn? |
From 6/30/22 dev meeting - It seems best for a subgroup to discuss involving @samreid @jonathanolson @liam-mulhall and @jbphet who have knowledge of rosetta and yarn. @jonathanolson voiced that he believes yarn has several advantages for the PhET code base at large. @liam-mulhall is going to move forward with Yarn v2 and it can be changed if the subgroup decides something else would be better. @zepumph: Why do we need two package.jsons? |
I'd like to better understand why we need 2 package.jsons, why yarn is better than npm, the costs (overhead) of adopting yarn in one place and whether we can jump over yarn and go straight to deno phetsims/chipper#1206 |
We don't necessarily need two
The main advantage of Yarn for my use case is that it supports a "monorepo" directory structure, where you have two (or more) repos in one directory. Yarn makes it so that dependencies aren't duplicated. For example, I use the Axios package in the client-side code and the server-side code. If I were to use NPM, I would have two copies of Axios, one for the client and one for the server. With Yarn, there's just one copy of Axios that is used on both the client and the server.
The latest version of Yarn can be configured to behave similarly to NPM. That is, we can have the familiar One cost of using Yarn is that AQUA will have to be configured to ask if a repository is an NPM repository or a Yarn repository before it pulls the most recent changes and runs ESLint.
Deno is appealing, but given that learning Deno would cost me more time, I would prefer to stick to Node. Let me know if you have more questions, @samreid! :) |
Thanks for the elaboration. Just wanted to ask a few clarifying questions:
Does this mean each developer and test machine (CT, phettest, build server, etc) will also need to do the equivalent of
Could this be nearly accomplished by having a package.json structure like so? {
"name": "rosetta",
"version": "1.00",
"devDependencies": {
// Used in client and server
"axios": "^7.15.0",
// Used only in client
"handlebars": "^7.15.0",
// Used only in server
"bun": "7.16.0"
}
} Of course this wouldn't be enforced the way yarn could enforce it, but maybe it is "good enough" if we decide that tooling change is too much of a hassle. (And we would need a way to put comments or equivalent in package.json files). Just trying to understand all the ramifications before we move forward, thanks for discussing! |
Ah, that's something I hadn't considered. Yes, I think any scripts that perform
If we found a reasonable way of putting comments in JSON, I suppose we could do it this way.
This is actually sort of a blocking issue for me. Right now, I'm moving forward with using the latest version of Yarn with I wish I could use Deno, but I think it would involve some non-trivial changes to the already-mature Rosetta 2.0 codebase that would require (probably?) too much time for me to implement. (My goal is to finish Rosetta 2.0 well before the end of Q3.) For example, I couldn't use Express in Deno, I'd have to use something like oak or Opine. Although I suppose I could use Node compatibility mode, but that seems like it might not be the best long-term solution. I suppose I could fiddle with Deno for an hour or two to see how difficult the transition would be. What are your thoughts on this, @samreid?
Of course! I'm happy to answer questions. Thanks for your feedback. |
Would it be easiest to just create a new repo that is specifically for the client? I also seems like it is most likely cheapest (depending on how much research and work has already gone into yarn). Do whatever you think is best, I just thought I'd say this out loud. |
Yes, it would definitely be easiest! However, I've discussed this with JB and SR, and we agreed that separate repos would add an unreasonable amount of maintenance burden.
Thanks, I appreciate your input! :) Sam and had a fairly in-depth discussion over Zoom where I clarified my motivation for using Yarn, and the plan is to move forward with Yarn. I'm going to do some reading about the new Plug'n'Play scheme available in version 2 before I decide between it and good old |
The critical parts of my zoom conversation with @liam-mulhall were:
|
Okay, I did a pretty deep dive on Yarn. Here's what I found out: Overview
Killer Features of Yarn
Yarn V1
Yarn V2
|
In doing my deep dive on Yarn, I found out that NPM also supports "workspaces" (a feature Yarn is known for), which enable support for a directory structure like the following:
In the root
So I think this will allow me to achieve all of my goals. It allows me to separate the client dependencies and the server dependencies, it allows me to use Create React App (or some other auto-scaffold thing), and using NPM instead of Yarn means I don't have to update AQUA, for example, to handle a repo that uses Yarn. |
@liam-mulhall - I'm good with the decision to continue with NPM. Can this issue be closed? |
Yes. @samreid and I came to the conclusion that it wouldn't make sense to introduce Yarn as a package manager because it would require us to add code to repos like AQUA that interact with an active repo's package manager. |
John and I are wondering whether it would be a good idea to use Yarn with the new version Rosetta because it would be nice to separate the client-side code and the server-side code. This would entail a monorepo structure like:
John and I are in agreement that it would be best to keep the code for the client and the server in one Git repository as opposed to splitting the code into two Git repositories.
It seems like the disadvantages to two separate repositories are myriad. One of the potential disadvantages to a monorepo for Rosetta is integrating PhET's
Gruntfile.js
and working smoothly with AQUA would probably be difficult.John and I would like to discuss this with the rest of the devs at the next dev meeting.
The text was updated successfully, but these errors were encountered: