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
--libor--appat 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--libto 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 foobarvsnpm 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.