Open mvhenten opened 6 years ago
Ok. Let me take a shot at this.
Why /packages
? Why not just /src
or some such?
yw
I know /src is advocated in a number of places - This may have to do with an older practice of putting non-source code files in a package, like some linux and other distribution mechanisms do.
Within the context of this repo, most files in the repository are considered source code by definition, and thus logic dictates we should move almost all the files into that directory.
The purpose of /packages
is not to merely store source code, it is to distinguish that which will be a package and depended on by other packages, and code that is used to manage this repo.
Additionally I do not expect anything else besides source code to live in this repo.
Can you provide a counter-argument for avoiding "packages"? I fail to come up with anything better and I am open to suggestions.
This moves all committed dependencies from
node_modules
andplugins/node_modules
into a packages directory, verbatim.I've updated scripts/install-sdk.sh to reference packages using
npm link
. This works perfect for all non-windows users.I suggest we could add some kind of install.bat file (is that still a thing on windows?) and use
MKLINK
.Eventually we should satisfy all dependencies using a simple postinstall. right now, several of our modules appear to be broken on npm so let's first fix those.
Why packages?
I've picked
packages
(as opposed to modules ) with the following considerations:They are packages - build artifacts that will be published as an NPM package, and installed as a _nodemodule. They contain a package.json and one or more modules.
The name modules is very closely related to _nodemodules. We expect to consume _nodemodules directly, whereas these packages should intentionally not be aware of each other (except as published npm packages).