-
Notifications
You must be signed in to change notification settings - Fork 101
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
Package manager abstraction #420
base: main
Are you sure you want to change the base?
Conversation
@julienrf @sjrd comments would be appreciated. Could I get some permissions to run CI at will, scripted tests are kind of clunky on my local machine. I could fix up tests that were broken prior to this PR too, but I will need to edit actual CI scripts because I have a feeling it needs some tinkering with Node/npm versions. I do not see where those |
Also, this very much breaks the backwards compatibility, but I assume that it is fine since the plugin is not v1 yet 😅 Let me know if that is not alright, there is definitely a way to stay backwards compatible, although the old design should be deprecated eventually - things like having both npm and yarn settings available simultaneously are obviously clunky. |
I will try to find some time for it this week. |
packageManager.value match { | ||
case aps: AddPackagesSupport => | ||
aps.addPackages(baseDir, installDir, log)(s"jsdom@$jsdomVersion") | ||
} |
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.
There should be a case _ =>
here, which shows a clear error message to the user, through a throw new MessageOnlyException("error message here")
.
val useYarn: SettingKey[Boolean] = | ||
settingKey[Boolean]("Whether to use yarn for updates") |
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 should preserve all these keeps as @deprecated
for compatibility reasons.
We can initialize packageManager
based on the value of those deprecated settings.
*/ | ||
val useYarn: SettingKey[Boolean] = | ||
settingKey[Boolean]("Whether to use yarn for updates") | ||
val packageManager = SettingKey[PackageManager]( |
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 should be called jsPackageManager
, to reduce the likelihood of collision with other sbt plugins.
useYarn := true | ||
packageManager := scalajsbundler.Yarn() |
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 should therefore keep a test that uses the deprecated useYarn
, in addition to the test that uses the new packageManager
.
npmExtraArgs in Compile := Seq("-silent"), | ||
packageManager in Compile := Npm(installArgs = Seq("-silent"), addPackagesArgs = Seq("-silent")), |
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.
Same here. We'll need to keep one test that uses npmExtraArgs
.
@@ -21,12 +22,10 @@ object NpmUpdateTasks { | |||
def npmUpdate(baseDir: File, |
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 should keep a deprecated overload of this method for compatibility reasons, which will delegate to this one.
Also the Scaladoc needs updating.
@@ -45,18 +44,16 @@ object NpmUpdateTasks { | |||
def npmInstallDependencies(baseDir: File, |
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.
Same here.
@@ -31,7 +31,8 @@ object PackageJsonTasks { | |||
webpackVersion: String, | |||
webpackDevServerVersion: String, | |||
webpackCliVersion: String, | |||
streams: Keys.TaskStreams | |||
streams: Keys.TaskStreams, | |||
packageManager: PackageManager | |||
): BundlerFile.PackageJson = { |
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.
Same here, and for the other methods below. We should keep deprecated aliases.
@@ -0,0 +1,2 @@ | |||
> fastOptJS::webpack | |||
$ exists package-lock.json |
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.
Missing EOL.
@@ -1 +1,2 @@ | |||
> fastOptJS::webpack | |||
$ exists yarn.lock |
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.
Missing EOL.
@sjrd Thank you for a very thorough review! I will make the changes as requested. |
4ef34f7
to
e7413d9
Compare
- name: Enable Corepack | ||
run: corepack enable | ||
- name: Setup yarn | ||
run: npm install -g yarn@1.22.15 | ||
run: corepack prepare yarn@1.22.15 --activate | ||
- name: Setup pnpm | ||
run: corepack prepare pnpm@7.0.1 --activate |
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.
Managing package manager installations inside and outside Corepack do not mix well, so we got to do it with Corepack only.
@sjrd I think I made all of the modifications you requested, PR is ready for a review. I also updated docs. |
} | ||
|
||
trait LockFileSupport { | ||
val lockFileName: String |
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.
It would be better to convert this to a File
to allow for better lockfile location customization.
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.
Though I do not have the best idea on where to put PackageManager.Npm
and PackageManager.Yarn
so that baseDirectory
is available during construction.
Currently scalajs-bundler will always update the lock file, making working directory dirty on CI. See scalacenter/scalajs-bundler#420 and scalacenter/scalajs-bundler#406
@ptrdom Thanks for this PR, would love to use pnpm with Scala.js. :) Anything missing for this PR to be merged? |
@sjrd .. Can we request a review of this. I would be happy to add bun support as well on top of this. Either way the JS community has much faster options than NPM right now which we should take advantage of. |
I think this PR was ignored for long enough to assume that maintainers are not accepting any PRs to actually develop features, which is fine, but it would have been considerate towards community to explicitly state that. My suggestions for plugin users who want a package manager abstraction:
|
References #417.
Main idea is to make a package manager abstraction that allows a flexible interaction with plugin's internals so that user's can extend the behavior however they wish.
TODO:
pnpm
.