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

npm libs in version catalogs #671

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

Conversation

Vampire
Copy link
Contributor

@Vampire Vampire commented Feb 9, 2023

What?

Handle version for NPM libs that are defined in a version catalog.

Why?

So that you get version update comments for NPM libs in the version catalog.
How to define and use them can be seen at https://youtrack.jetbrains.com/issue/KT-56416/KJS-Gradle-npm-compatibility-with-Gradle-version-catalogs

How?

Most things were in place already, I just needed to adjust 3 spots to handle NPM dependencies accordingly.

Testing?

Manually with my setup-wsl project.

@Vampire Vampire force-pushed the npm-libs-in-version-catalogs branch from 74ff323 to 27fbc94 Compare July 6, 2023 07:29
@LouisCAD LouisCAD self-assigned this Jul 6, 2023
Comment on lines 25 to -26
internal fun Dependency.matches(moduleId: ModuleId): Boolean {
return moduleId.group == group && moduleId.name == name
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This leads to an allocation on every single matches check, that's the reason why I didn't just use the conversion trick.

Could you revert this change?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No I can not, otherwise it does not work anymore, that was not just a cosmetic change:

moduleId.group == group && moduleId.name == name
actions == null && cache == @actions/cache
moduleId == moduleId()
Npm(group=actions, name=cache) == Npm(group=actions, name=cache)

I can try to reprogram it so that still the necessary calculation is done but no allocation necessary maybe.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Forgot to mention that I did. :-)

this::class.simpleName == "NpmDependency" -> {
return versionsCatalogLibraries.any {
val moduleId = npmModuleId()
it.module.group == (moduleId.group ?: "<unscoped>") && it.module.name == moduleId.name
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This "<unscoped>" thing is a a convention you defined, that isn't standard, right?
Isn't it possible to just have no group (i.e. null) instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it is a convention I invented and also suggested in the mentioned https://youtrack.jetbrains.com/issue/KT-56416/KJS-Gradle-npm-compatibility-with-Gradle-version-catalogs ticket.
I hope for it to become the official standard once that ticket maybe gets attention.

Just having semver = { module = "semver", version.ref = "semver" } does not work, as the version catalog parser complains it is not valid syntax.
Same for semver = { module = ":semver", version.ref = "semver" }, invalid syntax.
So you need the colon and you need something before it.
semver = { module = "null:semver", version.ref = "semver" } would be valid in the version catalog, but actually "null" would be a valid scope too and could also easily confuse users, so I decided to use something that clearly says it is an unscoped package and is very unlikely to be used as actual scope if it is even a valid scope name, hence "<unscoped>".

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What I would hope is for Gradle to allow null group as they do when not using version catalogs, that'd cut down the noise. On the other hand, unscoped dependencies are not that great of a thing, so maybe making it super obvious might be a good thing… 🤔

@Vampire Vampire force-pushed the npm-libs-in-version-catalogs branch from 27fbc94 to 056e1a8 Compare July 21, 2023 10:09
@Vampire Vampire requested a review from LouisCAD July 21, 2023 10:10
@Vampire Vampire force-pushed the npm-libs-in-version-catalogs branch from 056e1a8 to 519e0cf Compare August 1, 2023 14:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants