This PR changes the syntax of create-neon to require the user to explicitly specify the Neon project type, either by passing --lib or --app at the command-line, or otherwise by interactively asking them via stdin.
The reason for this is a limitation of npm init: the only way it will forward an argument like --lib to create-neon is if the user remembers to prefix it with --:
npm init neon -- --lib my-project
Without the extra --, npm silently ignores the --lib, which is a subtle and surprising hazard. This pitfall is easy to stumble into and difficult to debug.
(I built a demonstration package called create-dherman that you can use to test this behavior. Test it out with npm init dherman --lib foobar vs npm init dherman -- --lib foobar, for example.)
With this PR, users still need the --, but if they forget it, they'll be asked the project type interactively.
This PR changes the syntax of create-neon to require the user to explicitly specify the Neon project type, either by passing
--lib
or--app
at the command-line, or otherwise by interactively asking them via stdin.The reason for this is a limitation of
npm init
: the only way it will forward an argument like--lib
to create-neon is if the user remembers to prefix it with--
:Without the extra
--
, npm silently ignores the--lib
, which is a subtle and surprising hazard. This pitfall is easy to stumble into and difficult to debug.(I built a demonstration package called create-dherman that you can use to test this behavior. Test it out with
npm init dherman --lib foobar
vsnpm init dherman -- --lib foobar
, for example.)With this PR, users still need the
--
, but if they forget it, they'll be asked the project type interactively.