CLI Spec Proposal

[Fishrock123]

No description provided.

[yoshuawuyts]

s/sspeciality/speciality/ or perhaps "special"

[creationix]

Love the PR!

Interesting addition with the no-bundle option. I'd like to think about this use case more. In particular I need to know how much the problem is habitual inertia from people coming from node.js where projects are file based and don't have a bundle. Or in other words, is it because people are used to working with node and thus think of nucleus in terms of node's interface.

To me it's something else entirely, but I have the unique advantage of working with the same model with luvi and luvit for over a year in production. To me nucleus shouldn't ever replace node in the sense that people deploy scripts loose on a file system and then just use a nucleus implementation to run them. This will cause strong forces for scope creep in this project to support such use cases instead of delegating that to a node-like project that is built on top of nucleus. That would undo the entire purpose of this micro-kernel like design.

FS bundles should only be used for development convenience where the build step creating the zip and appending it is optional. But as I have discovered painfully in production with luvit, the fs bundle needs to act exactly the same as the final bundle when it is zipped.

Tests are a special case and I'm fine with supporting them, but I don't want to break the self-contained bundle model. In luvit world, the lit package manager supports a "files" directive in package.lua that allows package and app authors to specify which files in the git tree are included in the library or app. This way things like tests and documentation don't need to be included in production builds (npm trees for production projects are a nightmare in bloat). What if we just had a convention of tests/* within the same bundle as the app would be tests, but not be included when published. At least not included in the lists of files required to run the app. We can include them for purposes of CI at a package repository level. Just like the "dependencies" and "devDependencies" split in npm, we could have a split in files included.

The only technical problem I see with the CLI is a way to specify a custom main with a custom root. In the test case, we would want to run "foo/tests/run-all.js" or "foo/tests/some-test.js" with "foo" being the root of the bundle and not "foo/tests" as it currently done automatically in seaduk when you specify a file for the bundle.

We could have it look for a parent folder containing "main.js" and assume that's the root. We would probably still want an optional CLI option to specify the root manually as well.

So how about instead of the -N option, we add an option -r or --root? (Or it could be called base as is done in the bundle API, should probably be consistent either way we go).