Watcher task

[zewa666]

Hi there, this is a pretty interesting project. I personally feel a bit hesitant to introduce a new install command into the cli, its simply one more task to learn, but a good fit for this plugin.

Currently, I've been working on a simple task, which hooks into au build, reads the package.json, iterates over all dependencies and tries to upgrade aurelia.json itself. So I wondered whether this would fit for your tool as well? The idea is that the user wouldn't have to learn anything new, but the new task could integrate into existing ones and do the installation automatically, whenever the package.json file changes. I see that your project already has some really cool features, especially also the use of rfc6902 which makes updating aurelia.json even easier. 👍

Here is a small snippet of what I was building, to give you an idea.

let watch = function() {
  let packageJson = require("../../package.json");
  currentPackageJSONDeps = packageJson.dependencies;
  updateAureliaJSON();
  // gulp.watch(project.transpiler.source, refresh).on('change', onChange);
  // gulp.watch(project.markupProcessor.source, refresh).on('change', onChange);
  // gulp.watch(project.cssProcessor.source, refresh).on('change', onChange);
  gulp.watch("package.json").on('change', updateAureliaJSON);
}

let currentPackageJSONDeps = {};

function getDependencyDiffs() {
  let flattenedDeps = project.build.bundles[1].dependencies.map( (dep) => {
    if (typeof dep === "string") {
      return dep;
    }

    if (dep.name !== undefined) {
      return dep.name;
    }
  });

  return Object.keys(currentPackageJSONDeps).filter( (dep) => {
    if (flattenedDeps.indexOf(dep) === -1) {
      return dep;
    }
  });
}

function updateAureliaJSON() {
  let diffs = getDependencyDiffs();
  console.log(diffs);
  diffs.forEach( (dep) => {
    let depPackageJson = require(`../../node_modules/${dep}/package.json`);
    if (depPackageJson.main !== undefined) {
      let newDep = {
        name: dep,
        path: `../node_modules/${dep}`,
        main: depPackageJson.main.replace(".js", "").replace("./", "")
      }

      project.build.bundles[1].dependencies.push(newDep);
    }
  });

  const fs = require("fs");
  fs.writeFile('./package1.json', JSON.stringify(project), 'utf8'); 
}

[martonsagi]

@zewa666 Hi, thanks! What you got there is a pretty interesting idea too.

Currently, aurelia-cli-pacman is able to configure packages individually. I've deactivated the integrated npm installation by default, since it has its potential pitfalls. Letting users to use standard npm/yarn/whatever package managers sounds more reasonable.

I think implementing your idea - bulk update/restore in aurelia.json - would definitely be a big step toward better productivity. Defining bundle config based on package.json is cool! I could make use of it when a package has no predefined configuration.

I'll experiment with bulk processing feature using your snippet as starting point. Thank you! :)

Oh, sidenote: if you'd like to you use the integrated npm install, it can be reactivated easily. It's still there in pacman.js|ts custom task but it's been commented out.

    ...
    .then(result => {
        //return pacMan[cliParams.action](cliParams.pkg)
        //    .then(ok => pacMan.configure(cliParams, ...result));

        return pacMan.configure(cliParams, ...result);
    })
    ...

[zewa666]

sounds great, looking forward to seeing what you come up with

[adriatic]

(explanation to Marton: Vildan and I are "old" friends, born in the same country. We are also both living outside our homeland (Vildan in Austria and I in USA). We had many discussions in last 18 months since I fell in love with Aurelia.)

Hi Vildan

Glad to see that your eyes caught the relevance of Marton's pacman concepts ( I did the same just a tad bit earlier). Let me explain the current situation as defined yesterday as it has a lot to do with next release of our Monterey project, which could be perceived as a "visual shell" for aurelia-cli. While Monterey has more ambitions that that, for the purpose of this notice, it is a sufficient definition.

Marton's pacman (properly restructured) is the piece that will allow Monterey to go beyond the boundaries established by current aurelia-cli - by allowing Monterey to support adding third party packages, once the initial app skeleton is constructed. So I approached Marton with the proposal to join our AureliaTools group to help is with Monterey - and he graciously accepted, without even knowing that I am 25% Hungarian 😏.

As my primary focus is to help Aurelia Community, I immediately approached Rob Eisenberg with the idea to solve Monterey needs together with aurelia-cli evolution. So, to spare you from all details that took place - here are the conclusions we made.

1. We created a new project aurelia-cli package importer #401 which will be "formatted" as an aurelia-cli PR. Rob will create the spec and Marton will be the project lead.
2. A few hours older project related to this is Monterey Package Importer (MPI) tool #400 which will be properly restructured to directly consume aurelia-cli package importer defined above.
3. The article Adding third party modules #393 presents a possible utilization of Monterey Package Importer (MPI) tool #400, which will actually use aurelia-cli package importer #401. No need to say that all these "inclusions" will be optimized properly - the net effect is that aurelia-cli package importer #401 will get immediate and heavy testing in Monterey, even before it gets added to aurelia-cli tool.

It would be great to add you to the team in any role you might consider - from peeking from a side to having a direct influence on the design.

Dobro vece i laku noc 😄

[zewa666]

Dobro jutro i pozdrav iz Austrije ;)

First of all let me say that I think this is a great opportunity for you @martonsagi to get into such a team of great people and forward looking architects. If not anything else I'm sure you can learn tons of great practices from these guys, so @adriatic wise move to get Marton onboard. I personally liked the way how he is developing his package in a clean and structured way, making it easy to read and follow, so I'm sure he will be a good fit for the Monterey Team.

I didn't yet find the time to properly look at Monterey (besides it being a town in a zombie book I'm currently reading 😆 ) but now I will do for sure. So please bear with me while I play catchup. Thanks for linking those issues up, I will go through them to get a better understanding of what you guys are up for.

As for participation, I'm pretty low on time, but what I can definitely do is provide you guys with use cases related to Aurelia-I18N. What I can and will also do is adapt the plugin as needed to conform to the needs of Monterey, so we can use that as a good testing candidate to see how far the CLI superset can be driven.

[martonsagi]

@zewa666 Thank you, I'm really happy to receive such positive feedback on my work! I find this a major opportunity as well. I'm only at the beginning to learn Monterey in details, but I've already learned a lot.

@adriatic While I didn't follow AureliaTools team's work closely earlier, I was very well aware of the amount of awesomeness you guys have. ;) (The fact that you are in part Hungarian makes my decision even better. Köszönöm :-))