Qt
  1. Qt
  2. QTBUG-40028

Package management for QML/JavaScript a la npm?

    Details

    • Type: Suggestion Suggestion
    • Status: Open
    • Priority: P3: Somewhat important P3: Somewhat important
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None
    • Environment:

      QML/JavaScript

      Description

      Perhaps having a package manager for QML/JavaScript would be nice, similar to what npm is to Node.js. Perhaps call it qpm, and make a site (e.g. qpm.qt-project.org) to show user-submitted packages.

      This would be a nice way to allow people to submit JavaScript modules and QML components and greatly help the community. I'm sure there would be many considerations, but well worth it.

        Issue Links

        No reviews matched the request. Check your Options in the drop-down menu of this sections header.

          Activity

          Hide
          Pierre Bertet added a comment - - edited

          I am not sure this bug is a duplicate of QTBUG-22356.

          I think the reporter was talking about a module system + package manager for QML modules similar to what npm is for Node or client-side technologies like Browserify or Webpack.

          The compatibility of this system with CommonJS / the npm ecosystem is secondary to me.

          This would include:

          • Removing the dependencies version numbers from the code itself, and replace them with a system similar to the npm’s package.json dependencies field.
          • Having the dependencies declared in a meta file (the npm package.json file), and placed on a dedicated subdirectory (node_modules for npm).
          • Using a version system (like Semver), so everyone agree on what a version upgrade mean. E.g. Major = break something, Minor = add something, Patch = fix something.
          • Having a CLI tool to search, install and update the dependencies, which also updates the meta file, e.g. qpm install calendar.
          • Having a dedicated registry / website (as suggested with qpm.qt-project.org).
          Show
          Pierre Bertet added a comment - - edited I am not sure this bug is a duplicate of QTBUG-22356 . I think the reporter was talking about a module system + package manager for QML modules similar to what npm is for Node or client-side technologies like Browserify or Webpack. The compatibility of this system with CommonJS / the npm ecosystem is secondary to me. This would include: Removing the dependencies version numbers from the code itself, and replace them with a system similar to the npm’s package.json dependencies field . Having the dependencies declared in a meta file (the npm package.json file), and placed on a dedicated subdirectory ( node_modules for npm). Using a version system ( like Semver ), so everyone agree on what a version upgrade mean. E.g. Major = break something , Minor = add something , Patch = fix something . Having a CLI tool to search, install and update the dependencies, which also updates the meta file, e.g. qpm install calendar . Having a dedicated registry / website (as suggested with qpm.qt-project.org ).
          Hide
          Alan Alpert added a comment -

          Yeah, this is something different. While integration with npm/common JS would allow use of their JS modules, and might reduce the need for Javascript packages tailored for QML, what if you want to share an LCDNumber component or something that's QtQuick and visual (but has no native components)?

          Show
          Alan Alpert added a comment - Yeah, this is something different. While integration with npm/common JS would allow use of their JS modules, and might reduce the need for Javascript packages tailored for QML, what if you want to share an LCDNumber component or something that's QtQuick and visual (but has no native components)?
          Hide
          Pierre Bertet added a comment -

          what if you want to share an LCDNumber component or something that's QtQuick and visual (but has no native components)?

          That module could just be on the npm registry, there is already different kind of modules: node only, browser only, pure js… it could just be a QML-only module, I don’t think that break the npm code of conduct. An engines property exists in the package.json file, it could be used to set the module as a QML module, with the version. Another solution would be to host all the QML-specific components somewhere else.

          For QtQuick itself, if we consider it to be the QML standard library, the LCDNumber component can just assume it to be here since it has been defined in the engines field. The QtQuick API used by the component would be reliable thanks to Semver.

          Show
          Pierre Bertet added a comment - what if you want to share an LCDNumber component or something that's QtQuick and visual (but has no native components)? That module could just be on the npm registry, there is already different kind of modules: node only, browser only, pure js… it could just be a QML-only module, I don’t think that break the npm code of conduct . An engines property exists in the package.json file, it could be used to set the module as a QML module, with the version. Another solution would be to host all the QML-specific components somewhere else. For QtQuick itself, if we consider it to be the QML standard library, the LCDNumber component can just assume it to be here since it has been defined in the engines field. The QtQuick API used by the component would be reliable thanks to Semver.
          Hide
          Jens added a comment - - edited

          Just thought it might be useful to mention http://qpm.io here as it provides essentially what this task suggests. Now we just need packages contributed.

          Show
          Jens added a comment - - edited Just thought it might be useful to mention http://qpm.io here as it provides essentially what this task suggests. Now we just need packages contributed.

            People

            • Assignee:
              Alan Alpert
              Reporter:
              trusktr
            • Votes:
              3 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated:

                Gerrit Reviews

                There are no open Gerrit changes