search

klemenoslaj / ong-cli

6 stars 0 forks source link

Usage with npm #1

Open boeckMt opened 2 years ago

boeckMt commented 2 years ago

This repository looks nice!

I recognized that in the main package.json one is advised to use yarn instead of npm. Should this only be for developers of this repo or also for users of the cli?

I tried this repo with npm and looks like it is working as well, if you use a few other commands.

https://github.com/klemenoslaj/ong-cli/blob/main/README.md

## Usage
1. Execute `yarn install`
+ `npm install` // but do not execute ngcc on packages/demo/package.json
3. Execute `yarn workspace @ong-devkit/cli build`
+ npm --workspace @ong-devkit/cli run build // https://docs.npmjs.com/cli/v8/using-npm/workspaces#running-commands-in-the-context-of-workspaces
4. Execute `yarn workspace demo ong`
+ npm --workspace demo exec ong  // https://docs.npmjs.com/cli/v8/commands/npm-exec
klemenoslaj commented 2 years ago

Hi there.

I'm glad you like it!

Should this only be for developers of this repo or also for users of the cli?

That's only for contributors, in an own project you're free to use any other package manager :+1: Sorry for not being clear, I will update the docs a bit.

I tried this repo with npm and looks like it is working as well, if you use a few other commands.

Yes, it should work fine but overall I believe one package manager should be used in the repository, to ensure the same versions of dependencies are used - kind of purpose of lock files.

All hypothetical here, since so far I am the only contributor 😂

FYI, so far this cli is not published to the NPM registry yet. If you would have a use of it, I could publish it

boeckMt commented 2 years ago

Yes, it should work fine but overall I believe one package manager should be used in the repository, to ensure the same versions of dependencies are used - kind of purpose of lock files.

Yes, you're right, that could potentially lead to different dependency resolutions if the two log files are not synced.

Until now I only tested it a bit, because we also have the need to build multiple angular libraries in one command. I created a small tool for it, but processes are not built in parallel and it is much easier.

Nevertheless, a few functions are in there I would like to keep.

I will build your CLI and try to use it standalone in our repo, to test if it could work for our use case.

klemenoslaj commented 2 years ago

Until now I only tested it a bit, because we also have the need to build multiple angular libraries in one command. I created a small tool for it, but processes are not built in parallel and it is much easier.

Yeah I had something similar before, a simple topological sort and sequential build of libraries. That however got very slow as the amount of libraries grew.

Nevertheless, a few functions are in there I would like to keep.

  • check if all libraries declared their dependencies correctly
  • set some versions from the main package.json in the libraries for which we currently use a placeholder that replaces the versions at build time.

Yes, was thinking of adding this to the ong too, but figured that probably better place for that would be Angular builder, so it would happen within the ng build itself, not at an independent detached process. But maybe it's better if we add it to ong and people can benefit without changing the builder in angular.json 🤔

boeckMt commented 2 years ago

Yeah I had something similar before, a simple topological sort and sequential build of libraries. That however got very slow as the amount of libraries grew.

We don't build at "runtime" only if a new version is created, so it's not that big of a problem for us. But faster builds are always nice ;) To use the libraries at "runtime" we have a path mapping in the tsconfig.

Yes, was thinking of adding this to the ong too, but figured that probably better place for that would be Angular builder, so it would happen within the ng build itself, not at an independent detached process. But maybe it's better if we add it to ong and people can benefit without changing the builder in angular.json 🤔

I think changing the builder is something that people rarely do, because if there are some new features from angular itself you have to migrate manually, but it would be definitely a better place.

Can you install a yarn workspace with some placeholders? This is the first thing I have to solve with npm and there workspaces. But if there is a solution for it, I think integrating version replacement at build time in the CLI would be helpful. I could help if we are at this place.

klemenoslaj commented 2 years ago

We don't build at "runtime" only if a new version is created, so it's not that big of a problem for us. But faster builds are always nice ;) To use the libraries at "runtime" we have a path mapping in the tsconfig.

💯 yeah. Building libraries during development is just way too slow.

Can you install a yarn workspace with some placeholders?

Sorry, I am not sure what exactly do you mean.

I think integrating version replacement at build time in the CLI would be helpful. I could help if we are at this place

I guess we can try already. The heavy lifting is done already, just checking the existing dependencies graph, then only writing into the package.json of the built libraries.

boeckMt commented 2 years ago

💯 yeah. Building libraries during development is just way too slow.

Ah, so you don't use ong-cli for building during development either?

Sorry, I am not sure what exactly do you mean.

I tried to describe it here https://github.com/npm/rfcs/issues/301#issuecomment-1076200854

E.g. the dependencies for angular in the demo/package.json use version ~13.3.0 and I want that all the libraries and components us the same for there peerDependencies. Or I have one dependency which is used in multiple of my libraries so I don't want to manage this versions manually for each.

Currently I don't use workspaces because when we created our repository, npm didn't support it yet. So I managed all dependencies in the main package.json (but I would like to get away from that). To define the versions for packages and libraries we used a placeholder 0.0.0-PLACEHOLDER-VENDOR which gets replaced with the version of the main package for the specified dependency at build time.

But this way npm is not capable to install a workspace because it doesn't know wich versions to use. Wanted to ask if something like this is possible with yarn.

I guess we can try already. The heavy lifting is done already, just checking the existing dependencies graph, then only writing into the package.json of the built libraries.

That sound really great :)