-
-
Notifications
You must be signed in to change notification settings - Fork 6.6k
feat(create-jest): Add npm init / yarn create initialiser
#14453
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
✅ Deploy Preview for jestjs ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site configuration. |
packages/create-jest/package.json
Outdated
| "./bin/create-jest": "./bin/create-jest.js" | ||
| }, | ||
| "dependencies": { | ||
| "jest-cli": "workspace:^" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's right. It can reused, I agree.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Left few quick notes.
Could you add create-jest to this list, please:
Line 114 in f2c78d0
| "typecheck:tests": "tsc -b packages/{babel-jest,babel-plugin-jest-hoist,diff-sequences,expect,expect-utils,jest-circus,jest-cli,jest-config,jest-console,jest-snapshot,jest-util,jest-validate,jest-watcher,jest-worker,pretty-format}/**/__tests__", |
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm.. import-local is not included in dependencies list?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed yargs to keep package lighter
Co-authored-by: Tom Mrazauskas <[email protected]>
…/jest into feat/create-jest-package
mrazauskas
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 |
packages/create-jest/src/errors.ts
Outdated
| 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. I'm happy with everything.
|
I updated the changelog with the new package |
SimenB
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
great stuff, thanks!
|
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 🙂