feat(create-jest): Add npm init / yarn create initialiser#14453
feat(create-jest): Add npm init / yarn create initialiser#14453SimenB merged 28 commits intojestjs:mainfrom
npm init / yarn create initialiser#14453Conversation
✅ Deploy Preview for jestjs ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site configuration. |
| "./bin/create-jest": "./bin/create-jest.js" | ||
| }, | ||
| "dependencies": { | ||
| "jest-cli": "workspace:^" |
There was a problem hiding this comment.
This means that the whole Jest with all its dependencies will be pulled? Or? I would expect the create- package to be a lightweight script. Did I miss something?
There was a problem hiding this comment.
Perhaps it makes sense to move the whole logic to the new package and deprecate the --init flag in Jest 30?
There was a problem hiding this comment.
This means that the whole Jest with all its dependencies will be pulled? Or? I would expect the create- package to be a lightweight script. Did I miss something?
I was thinking about standardised global wrapper for the initialisation (adapter for npx jest --init). For this purpose whole jest-cli is not necessary indeed.
Perhaps it makes sense to move the whole logic to the new package and deprecate the --init flag in Jest 30?
Sounds fine, or maybe we can reverse the dependencies and use create-jest inside jest-cli to keep the API the same
There was a problem hiding this comment.
In this case create-jest would get shipped with jest. I was thinking a new package like @jest/init could be introduced, but that requires major release as well. Other question, is there a need to have the --init command if create-jest gets introduced? By the way, moving the whole --init logic to create-jest would make jest leaner (e.g. only create-jest would ship prompts as dependency, if I didn’t miss something).
There was a problem hiding this comment.
One more idea, I think for now it would be fine to copy the code to create-jest and in jest-cli it could be marked with // TODO Remove in Jest 30 comment.
There was a problem hiding this comment.
That's right. It can reused, I agree.
There was a problem hiding this comment.
To summarize: in addition to this
- This PR will move the entirety of the
--initcommand implementation into this new packagejest-cliwill then have a dependency oncreate-jest, and delegate to it whenjest --initis called- A separate PR will be prepared for v30 (I'll add it to the milestone so we don't forget) which deprecates
--initand removes the dependency
we are also adding [rootPath] to JS and CLI API, right?
There was a problem hiding this comment.
we are also adding
[rootPath]to JS and CLI API, right?
How do you feel? I find it useful, but can be implemented later.
There was a problem hiding this comment.
Yeah, I think that's fine. --init will default to process.cwd(), but I do think it makes sense as part of the API
There was a problem hiding this comment.
How do you feel? I find it useful, but can be implemented later.
I also find it useful, makes sense to do it here I think, it's not that hard
| coverage: boolean; | ||
| coverageProvider: boolean; | ||
| environment: boolean; | ||
| coverageProvider: string; |
There was a problem hiding this comment.
Sorry for the extra diff, I had to fix tslint errors in this package. jest-cli code was ignored, but new package name ends with jest and it matches the condition in tslint script 😄
I decided to do a good thing and fix the errors instead of excluding the package from the script
|
I'll prepare separate PR with |
mrazauskas
left a comment
There was a problem hiding this comment.
Thanks! Left few quick notes.
Could you add create-jest to this list, please:
Line 114 in f2c78d0
jest-cli is there already, test files did not change, so the typecheck should pass.
| import exit = require('exit'); | ||
| import * as fs from 'graceful-fs'; | ||
| import prompts = require('prompts'); | ||
| import yargs = require('yargs'); |
There was a problem hiding this comment.
Just thinking out loud: it feels too much to ship yargs with this package. I think process.argv[2] would be to do the job. The value will be always string | undefined.
Currently this package is 15.5 kB (unpacked). yargs takes 292 kB (unpacked, without dependencies). That’s what npm gave to me.
There was a problem hiding this comment.
Sounds fair, I think keeping this package light is more important than having universal parsing for arguments and --help interface
| ); | ||
|
|
||
| if (hasJestProperty || existingJestConfigExt) { | ||
| if (hasJestProperty || Boolean(existingJestConfigExt)) { |
There was a problem hiding this comment.
| if (hasJestProperty || Boolean(existingJestConfigExt)) { | |
| if (hasJestProperty || existingJestConfigExt != null) { |
| ? getConfigFilename(existingJestConfigExt) | ||
| : path.join(rootDir, getConfigFilename(jestConfigFileExt)); | ||
| const jestConfigPath = | ||
| typeof existingJestConfigExt !== 'undefined' |
There was a problem hiding this comment.
| typeof existingJestConfigExt !== 'undefined' | |
| existingJestConfigExt != null |
| ): Promise<void> { | ||
| rootDir = tryRealpath(rootDir); | ||
| // prerequisite checks | ||
| const projectPackageJsonPath: string = path.join(rootDir, PACKAGE_JSON); |
There was a problem hiding this comment.
Interesting why ESLint did not catch this:
| const projectPackageJsonPath: string = path.join(rootDir, PACKAGE_JSON); | |
| const projectPackageJsonPath = path.join(rootDir, PACKAGE_JSON); |
| import * as fs from 'graceful-fs'; | ||
| import prompts = require('prompts'); | ||
| import yargs = require('yargs'); | ||
| import {getVersion} from '@jest/core'; |
There was a problem hiding this comment.
Importing @jest/core will ship almost the whole Jest with create-jest. Not sure if that is worth.
| * LICENSE file in the root directory of this source tree. | ||
| */ | ||
|
|
||
| const importLocal = require('import-local'); |
There was a problem hiding this comment.
Hm.. import-local is not included in dependencies list?
There was a problem hiding this comment.
Also not so sure if import-local is needed in this case. It does not make sense installing create-jest locally. To be honest, I don’t understand what import-local does ;D So it can be I missed something.
There was a problem hiding this comment.
I'm ok with removing that, local installation indeed seems strange in this case
| try { | ||
| const argv = await yargs(process.argv.slice(2)) | ||
| .usage('Usage: $0 [rootDir]') | ||
| .version(getVersion()) |
There was a problem hiding this comment.
If it is decided to keep yargs, this should be create-jest version. It will be used by create-jest --version, or?
There was a problem hiding this comment.
Removed yargs to keep package lighter
Co-authored-by: Tom Mrazauskas <tom@mrazauskas.de>
…/jest into feat/create-jest-package
mrazauskas
left a comment
There was a problem hiding this comment.
Thanks! Looks alright for me.
Not very happy to see runCLI() function being exported, but I understand that there are some limitation since --init has to reuse the logic. This can be cleanup up in the future.
|
Just a detail, there is no mention of Hm.. Hard to say where it belongs. Does it make sense to suggest Perhaps for now |
"Getting Started" makes the most sense to me |
@mrazauskas I also don't like it, actually we don't need it in So I can remove the export, but in |
| super( | ||
| `There is malformed json in ${packageJsonPath}\n` + | ||
| 'Fix it, and then run "jest --init"', | ||
| 'Fix it, and then run "create-jest" again', |
There was a problem hiding this comment.
Good catch! I'm just not sure if the new suggestion is right. People using --init will see it too, right? Also user does not run create-jest directly. Hm.. Perhaps it's enough to say that the file is malformed?
There was a problem hiding this comment.
Sounds good, thanks for the idea!
|
Does it manage to generate commands for Yarn Classic and Yarn Berry? I'm on mobile and can't remember the details, but the commands are different. Perhaps |
|
Right, it works. See: yarnpkg/berry#1138 |
Great! Do we need to add something else here (except for changelog update)? |
mrazauskas
left a comment
There was a problem hiding this comment.
Thanks. I'm happy with everything.
|
I updated the changelog with the new package |
|
Reference regarding the CI failures on Node.js 20.6: nodejs/node#49497 |
f24ea7f to
9e3ddfa
Compare
|
Very cool, thanks for building this! |
|
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |


Summary
Jest already has jest
--initwizard which makes initial setup very fancy, but it doesn't have starter-kit wrapper for package managers, like npm init or yarn createDetails in this issue
Test plan
I checked the approach on my own package on
yarn,npm,pnpm(see usage increate-jestreadme), but I don't have access tocreate-jestpackage, so I'm not able to test it completelyBut just in case I also checked JS-API of the packed package like this
Also not sure if it's worth to add e2e for this package, please ping me if it is 🙂