Local dependencies in package.json of JS/MPP projects

I noticed that since version 1.4.0, MPP (and JS?) projects targetting NodeJS produce package.json files where dependencies point to local files.

For instance:

"dependencies": {
    "kotlin": "file:/path/to/project/build/js/packages_imported/kotlin/1.4.10",
    "kotlin-test-js-runner": "file:/path/to/project/build/js/packages_imported/kotlin-test-js-runner/1.4.10",
    "kotlin-test": "file:/path/to/project/build/js/packages_imported/kotlin-test/1.4.10"
  },

instead of

"dependencies": {
    "kotlin": "^1.4.10",
    "kotlin-test-js-runner": "^1.4.10",
    "kotlin-test": "^1.4.10"
  },

This is of course a problem if one needs to publish the generated JS code on NPM.

Questions:

  • is this intended?
  • how can one avoid this? (i.e. How can one produce the second sort of package.json instead of the first one?)

Yes, it is intended, there is task :publicPackageJson, which produce package.json with only non-file dependencies.
The problem with producing Kotlin/JS module dependencies as a non-file dependencies is that you can use dependency which is not provided by NPM registry.

The similar question is here

Thank you, Ilya for your answer.
Maybe that task is called jsPublicPackageJson on multi-platform projects?
I tried to run the :publicPackageJson task on my MPP project and I get the following message:

Task 'publicPackageJson' not found in root project 'kt-math'. Some candidates are: 'jsPublicPackageJson'.

However, assuming the task you mentioned is actually called jsPublicPackageJson on MPP projects, either it is buggy or I’m not using it correctly.
In fact, if I run the jsPublicPackageJson package alone in my MPP project, the generated package.json file is as follows:

{
  "main": "kotlin/kt-math.js",
  "devDependencies": {},
  "dependencies": {
    "kotlin": "file:/mnt/hdd/home/gciatto/Work/Code/kt-math/build/js/packages_imported/kotlin/1.4.10",
    "kotlin-test-js-runner": "file:/mnt/hdd/home/gciatto/Work/Code/kt-math/build/js/packages_imported/kotlin-test-js-runner/1.4.10",
    "kotlin-test": "file:/mnt/hdd/home/gciatto/Work/Code/kt-math/build/js/packages_imported/kotlin-test/1.4.10"
  },
  "peerDependencies": {},
  "optionalDependencies": {},
  "bundledDependencies": [],
  "name": "kt-math",
  "version": "0.2.0"
}

Is some configuration needed to make that task generate a package.json with no file dependency?

BTW, it is not clear to me why kotlin-test* dependencies are added to the main project in the first place.

Yes, in multiplatform projects it is :jsPublicPackageJson task. It creates package.json file in build/tmp/publicPackageJson
Do you get file:/... dependencies in this?

Containing of kotlin-test seems a bug, sorry for that

Wouldn’t be ideal a task that webpacks only Maven dependencies and declare in package.json only the ones from NPM? That would create the perfect library.

The only problem remaining would be libraries published both on NPM and Maven like the kotlin-stdlib.

Maybe a configuration block to explicitly declare the link?

@ilya.goncharov there are several issues with the js*PackageJson tasks, which can be better understood in a multi-project & multi-plaftorm setting, such as 2P-Kt:

  • the package.json generated by jsPublicPackageJson has no dependencies at all
  • the package.json generated by jsPublicPackageJson is in the project’s build directory, whereas the one generated by jsPackageJson is in the rootProject’s build directory
  • the package.json generated by jsPackageJson exposes two dependencies, namely kotlin-test and kotlin-test-js-runner which should actually be dev dependencies
    • (notice that kotlin-test-js-runner is not even published on NPM)

Yes, it can be one of options. Additionally we want to make experience consistent with IR compiler, where you compile all Kotlin code (includeing Kotlin libraries) together into JavaScript file(s)

Thanks, I’ll take a look into this project
About points:

It should be actual if you have no NPM dependencies. And especially for now it is expected. :jsPublicPackageJson includes only external NPM dependencies.

That’s true. Providing npm project in root project solve the problem of huge node_modules folder, which we don’t want to duplicate in all Kotlin/JS modules, and reduce total installing dependencies time. As for jsPublicPackageJson it is just generating of file, which you can use anywhere you want

Yes, I think especially kotlin-test is a strange thing. And we should rename kotlin-test-js-runner because now it is useful utils for our Gradle-Kotlin/JS integrations, not only for testing

You are right, we consider publishing this as a package into NPM registry. But it is useful really only in integration with our Gradle plugin, it is not for installing it into pure JavaScript project

@ilya.goncharov
It should be actual if you have no NPM dependencies. And especially for now it is expected. :jsPublicPackageJson includes only external NPM dependencies.

Wait, are you saying that if I have two subprojects :A and :B where :B depends on :A, then the package.json generated by :B:jsPublicPackageJson should not include the dependency from A?

@ilya.goncharov
That’s true. Providing npm project in root project solve the problem of huge node_modules folder, which we don’t want to duplicate in all Kotlin/JS modules, and reduce total installing dependencies time. As for jsPublicPackageJson it is just generating of file, which you can use anywhere you want.

I see. Thanks for the info.

@ilya.goncharov
Yes, I think especially kotlin-test is a strange thing. And we should rename kotlin-test-js-runner because now it is useful utils for our Gradle-Kotlin/JS integrations, not only for testing

Should I open an issue to recall making kotlin-test* dev dependencies?

Wait, are you saying that if I have two subprojects :A and :B where :B depends on :A , then the package.json generated by :B:jsPublicPackageJson should not include the dependency from A?

Exactly, it includes dependency on project A, which will include its own dependencies

Should I open an issue to recall making kotlin-test* dev dependencies?

Feel free, thanks!

1 Like

I think this is a bit misunderstood.

If there are two subprojects :A and :B where :B depends on :A, then I would expect :B:jsPublicPackageJson to include a dependency on :A.

At the moment, it doesn’t.

(If :A has dependencies on its own, it should, of course, be in :A:jsPublicPackageJson.)

2 Likes