-
Notifications
You must be signed in to change notification settings - Fork 795
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
fix(sys): make NodeLazyRequire complain if package versions aren't right #3346
Conversation
25359e6
to
24eb9d2
Compare
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.
Implementation looks good to me! Just a few asks for tests
header: 'Please install supported versions of dev dependencies with either npm or yarn.', | ||
messageText: 'npm install --save-dev jest@38.0.1', | ||
}); | ||
}); |
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.
Could we add one more test here to verify that this returns an error for prereleases? E.g.
}); | |
}); | |
it('should error if the installed version of a package is too high (prereleases)', async () => { | |
const { nodeLazyRequire, readFSMock } = setup(); | |
readFSMock.mockReturnValue(mockPackageJson('38.0.1-alpha.0')); | |
let [error] = await nodeLazyRequire.ensure('.', ['jest']); | |
expect(error).toEqual({ | |
...buildError([]), | |
header: 'Please install supported versions of dev dependencies with either npm or yarn.', | |
messageText: 'npm install --save-dev jest@38.0.1', | |
}); | |
}); |
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.
makes sense - I parameterized this test and added that version string, and then also added a few more to the other test which tests what should be accepted as valid versions — 3bd58e2
|
||
describe('node-lazy-require', () => { | ||
describe('NodeLazyRequire', () => { | ||
function setup() { |
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.
since we're testing the ensure
method on NodeLazyRequire
, can we add a suite that wraps all this setup/tests?
describe('node-lazy-require', () => {
describe('NodeLazyRequire', () => {
describe('ensure', () => {
function setup() { .. }
...
it('should error if the installed version of a package is too high', async () => {
...
});
});
});
});
});
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.
sure, makes sense to me — 7414f82
describe('NodeLazyRequire', () => { | ||
function setup() { | ||
const resolveModule = new NodeResolveModule(); | ||
const readFSMock = jest.spyOn(fs, 'readFileSync').mockReturnValue(mockPackageJson('10.10.10')); |
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.
Can we make sure we clear this mock between tests? With the current setup, I think we're generally OK, in that we call setup
in each test, but I think might be a good idea to clean up in an afterEach
as well to be explicit about reseting things
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.
src/sys/node/node-lazy-require.ts
Outdated
private nodeResolveModule: NodeResolveModule, | ||
private lazyDependencies: { [dep: string]: [string, string] } | ||
) {} | ||
constructor(private nodeResolveModule: NodeResolveModule, private lazyDependencies: LazyDependencies) {} | ||
|
||
async ensure(fromDir: string, ensureModuleIds: 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.
Minor, can we JSDoc this function while we're in here?
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.
addressed in e452f2a
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.
Ahh sorry if I wasn't clear here - meant on the ensure()
method since we were getting it under test. The ctor JSDoc looks good though! Let's keep that 🙂
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.
no worries! just added that in 8c90322
@@ -119,7 +119,6 @@ | |||
"puppeteer": "~10.0.0", | |||
"rollup": "2.42.3", | |||
"rollup-plugin-sourcemaps": "^0.6.3", | |||
"semiver": "^1.1.0", |
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 removed this as a dependency since we were only using it in a few places and already depending on semver
.
I noticed references to this package in scripts/license.ts
and NOTICE.md
— is there any manual intervention needed to sort those out?
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.
possible nvm on this one - found scripts/license.ts
and ran it, see 684fe50
@rwaskiewicz I think I addressed all your comments |
describe('node-lazy-require', () => { | ||
describe('NodeLazyRequire', () => { | ||
describe('ensure', () => { | ||
let readFSMock: jest.SpyInstance; |
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.
Minor suggestion - can we add types to the spy here?
let readFSMock: jest.SpyInstance; | |
let readFSMock: jest.SpyInstance<ReturnType<typeof fs.readFileSync>, Parameters<typeof fs.readFileSync>>; | |
src/sys/node/node-lazy-require.ts
Outdated
private nodeResolveModule: NodeResolveModule, | ||
private lazyDependencies: { [dep: string]: [string, string] } | ||
) {} | ||
constructor(private nodeResolveModule: NodeResolveModule, private lazyDependencies: LazyDependencies) {} | ||
|
||
async ensure(fromDir: string, ensureModuleIds: 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.
Ahh sorry if I wasn't clear here - meant on the ensure()
method since we were getting it under test. The ctor JSDoc looks good though! Let's keep that 🙂
This updates a bit of logic in `NodeLazyRequire.ensure` to check that the installed versions of packages are within the specified version range, i.e. that `minVersion <= installedVersion <= maxVersion`. This commit also adds tests for that module. STENCIL-391: bug: @stencil/core does not throw error when missing jest/jest-cli deps in a rush/pnpm monorepo
8c90322
to
8c71d85
Compare
This updates a bit of logic in
NodeLazyRequire.ensure
to check thatthe installed versions of packages are within the specified version
range, i.e. that
minVersion <= installedVersion <= maxVersion
.This commit also adds tests for that module.
STENCIL-391: bug: @stencil/core does not throw error when missing
jest/jest-cli deps in a rush/pnpm monorepo
Pull request checklist
Please check if your PR fulfills the following requirements:
npm run build
) was run locally and any changes were pushednpm test
) were run locally and passednpm run test.karma.prod
) were run locally and passednpm run prettier
) was run locally and passedPull request type
Please check the type of change your PR introduces:
What is the current behavior?
GitHub Issue Number: N/A
If a stencil user has a package installed that's out of the range we current don't show an error, so we could end up just having runtime errors relating to unsupported differences in those packages.
What is the new behavior?
Now if the user does not have a version in the range we log an error instead!
Does this introduce a breaking change?
Testing
I wrote some tests, and tried out the behavior locally with a little test component.