I could also help with this.

To orchestrate the packages we could set up a simple NPM workspace in the node folder. The structure then becomes as follows:

├── addon
│   ├── package.json
├── addon-jackett
│   ├── package.json
├── consumer
│   ├── package.json
└── lib
    └── package.json
├── package.json

When everything is setup correctly you can then npm install lib in addon and consumer, which will symlink the shared lib package and make it available for import:

import { example } from 'lib';
// ...

Another upside to the workspace approach is you can share devDependendies between all packages by defining them once in the parent package.json file (node/package.json in this case).

@sleeyax amazing thanks! JavaScript isn’t my primary language, so I’m going with the flow here 😂.

This is a good idea. I’ll attempt this when I’m back online.

@sleeyax is lib a common convention in these situations for JS? I was trying to decide what the best name would be

@sleeyax you're more than welcome to fork and commit some changes and make a pull request 😆

Yep, was just about to do so @purple-emily you read my mind :)

Yep. Workspaces is what we should use, rather than sub npm packages or github packages
I was gonna add Nx though - so we can cache build artifacts for individual package builds within git and share between us
No Nx cloud though - all disconnected

https://nx.dev/getting-started/intro
https://nx.dev/nx-api/esbuild

It handles caching of build and test artifacts, less duplication of config files etc
Plus i'd like to start rewriting some of our ES modules as typescript to get some damn type checking added for dev lol
All this dynamic typing makes me feel like i need 5 showers a day 👅

This will close #56.

I'd like some help with this when anyones available, but I don't mind doing what I can for now. Ideally @iPromKnight you'll add me on Discord and help me quickly work out if I have the correct dev environment set up for JS 😂

Ahh I hardly use it these days - you should see my unread message count hahaha
Sure can do - but it sounds like @sleeyax might be a better fit

I'm a .net dev really 23 years of it - this is the first JS project i've worked on in the past 4 years - although it seems not much has changed just tooling has gotten better ^^

Yep. Workspaces is what we should use, rather than sub npm packages or github packages

I was gonna add Nx though - so we can cache build artifacts for individual package builds within git and share between us

No Nx cloud though - all disconnected

https://nx.dev/getting-started/intro

https://nx.dev/nx-api/esbuild

It handles caching of build and test artifacts, less duplication of config files etc

Plus i'd like to start rewriting some of our ES modules as typescript to get some damn type checking added for dev lol

All this dynamic typing makes me feel like i need 5 showers a day 👅

Don't let me stop you 😂 I don't know what @sleeyax has done already

Oh okay, I've used nx before so can add the base setup for that too. Not sure if a shared cache is warranted (as in really needed) at the current stage of this project though, perhaps this should be a new issue for improvement?

Plus i'd like to start rewriting some of our ES modules as typescript to get some damn type checking added for dev lol

Perfect. It's actually insane this project isn't using typescript already haha.

Really is

Oh okay, I've used nx before so can add the base setup for that too. Not sure if a shared cache is warranted (as in really needed) at the current stage of this project though, perhaps this should be a new issue for improvement?

Plus i'd like to start rewriting some of our ES modules as typescript to get some damn type checking added for dev lol

Perfect. It's actually insane this project isn't using typescript already haha.

Haha I hear ya - so frustrating
It was all pure js when we originally took the old code too, had the pain of changing all imports, and introducing esbuild so we could transpile

the shared cache is just built in - gets stored in the .nx folder if we don't use nx cloud - so can just commit it
Just means faster local builds etc

Yeah I was surprised to see tsx being used in a non-typescript project too 😆

Yeah I was surprised to see tsx being used in a non-typescript project too 😆

Haha - I only added recently - but that was part of the plan to move us forward. -plus we can still use watch, and pipe it into pino now i've added that too for pretty logs during dev

Please consider moving moch's to a separate lib too, That way our only upstream (torrentio) commits to mochs for the time being will be to that lib - nothing else should hopefully have to change

And once we have the moch's rewritten - we'll have to support those too

Who knows - maybe Torrentio's author will end up pulling some of the improvements from us lol

Ouch setting up nx is a little more complex than I remember, it pretty much requires a project.json per project with the esbuild executor configured which in turn requires a tsconfig.json file to be present per project which is iffy since we're not using typescript yet 😅

I'll go ahead and create a PR for the NPM workspace restructure first so @purple-emily can continue moving shared code to the common lib. The nx setup can then be continued in parallel.

See #60

Ouch setting up nx is a little more complex than I remember, it pretty much requires a project.json per project with the esbuild executor configured which in turn requires a tsconfig.json file to be present per project which is iffy since we're not using typescript yet 😅

I'll go ahead and create a PR for the NPM workspace restructure first so @purple-emily can continue moving shared code to the common lib. The nx setup can then be continued in parallel.

See #60

Might be worth holding off on moving stuff to the shared codebase right now - The addon is 85% typescript in my pr draft now in #69
Wouldn't mind you having a look over ^^ ta