create-neon #690
create-neon #690
Conversation
|
Hi @dherman! Look on this PR neon-bindings/create-neon-lib#1. It may be useful for it |
create-neon/package.json
Outdated
| "bin": "./dist/bin/create-neon.js", | ||
| "files": [ | ||
| "dist/**/*", | ||
| "templates/**/*" |
This comment was marked as duplicate.
This comment was marked as duplicate.
Sorry, something went wrong.
- Abstracted handlebars template logic into a Template class - Abstracted the template context type into a Metadata module with some type definitions - Better error messages - Infer the N-API version from the current process - Drop the Neon patch version number from the generated manifest - Use JSON.stringify for quoting text
…e environment variables through to npx.
- eliminate `+` hack
create-neon/src/metadata.ts
Outdated
| // we can use, so we have to guess based on the default value. This also | ||
| // unfortunately leaks to the user when `npm init` shows the values for | ||
| // the package.json it's going to use in the final user confirmation. | ||
| if (!/\s*echo \".*\" && exit 1\s*/.test(json.scripts.test)) { |
There was a problem hiding this comment.
If we write a package.json before executing npm init that contains { "scripts": { "test": "cargo test" } }, it won't prompt for a test command. I think this might be a cleaner workaround than matching on the default text because the user won't even be prompted.
create-neon/src/metadata.ts
Outdated
| } | ||
|
|
||
| constructor(json: any, cargoCpArtifact: string) { | ||
| this.json = json; |
There was a problem hiding this comment.
Why do we have two copies of the data? Overall, I find the class base approach a little complicated. Alternatively,
interface PackageJson {
name: string,
author: string,
[k: string]: any,
}There might be a package.json types file we could import.
…he package.json up front with default values.
- Delete test output directory after every test - Add test output directories to gitignore - Add npm-debug.log to gitignore template
There was a problem hiding this comment.
@dherman This looks really good! I like that we start with a fully functional package.json. This way even if the user cancels the prompts, they still end up with a fully functional project.
…r supported Node versions.
…airly slow and there aren't very many tests anyway.
Good thought, I'm running that approach through CI to see if it works on Windows. Seems a bit more robust if so. |
Initial implementation of the
create-neonCLI, as described in the Streamlined UX RFC.