Skip to content

Remove unused code #2817

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

Merged
merged 5 commits into from
Mar 31, 2020
Merged

Remove unused code #2817

merged 5 commits into from
Mar 31, 2020

Conversation

schmidt-sebastian
Copy link
Contributor

@schmidt-sebastian schmidt-sebastian commented Mar 28, 2020

This PR removes unused code from the SDK (as shown by running the integration tests with coverage). It's only a small improvement, but it should not be harmful.

@google-oss-bot
Copy link
Contributor

google-oss-bot commented Mar 28, 2020

Binary Size Report

Affected SDKs

SDKTypeBase (aab78f9)Head (2767824)Diff
@firebase/firestore/memorybrowser224475.00223853.00-622.00 (-0.28%)
module221655.00221033.00-622.00 (-0.28%)
esm2017170304.00169771.00-533.00 (-0.31%)
main397404.00396478.00-926.00 (-0.23%)
@firebase/firestorebrowser271055.00270233.00-822.00 (-0.30%)
module267834.00267012.00-822.00 (-0.31%)
esm2017216141.00215482.00-659.00 (-0.30%)
main488418.00487037.00-1381.00 (-0.28%)
firebasefirebase.js846872.00846061.00-811.00 (-0.10%)
firebase-firestore.memory.js266750.00266140.00-610.00 (-0.23%)
firebase-firestore.js311995.00311184.00-811.00 (-0.26%)
Metric Unit: byte

Test Logs

// Escape the promise chain and throw the error globally so that
// e.g. any global crash reporting library detects and reports it.
// (but not for simulated errors in our tests since this breaks mocha)
if (message.indexOf('Firestore Test Simulated Error') < 0) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is still used, isn't it?

const expected = new Error('Firestore Test Simulated Error');

You mentioned in the PR description that you ran the integration tests... did you run the unit tests also? Because it seems like the unit tests should fail with this line removed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is special handling of test code that is no longer needed, since we are not using mocha anymore (karma runs our browser tests). So the same test passes now without this special handling.

As for running the unit tests - all tests run as part of CI, and I usually run them locally as well. There are some tests that are "harder" to run locally, such as the minified integration tests (see /integration/firestore), but even those are run in CI.

* always terminated with a separator, and so a successor can always be
* cheaply computed by incrementing the last character of the path.
*/
export function prefixSuccessor(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just for my own information, is it acceptable to delete exported functions as long as they are not "publicly exported" in https://github.com/firebase/firebase-js-sdk/blob/master/packages/firestore-types/index.d.ts? Otherwise, wouldn't this be a backwards-incompatible change?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general, if code is not in the api/ folder, it can't be used by our users.

In more technical terms, only code that is exported from our index.ts files is considered part of the public API:
https://github.com/firebase/firebase-js-sdk/blob/master/packages/firestore/register-module.ts

Furthermore, the files under /api should match our types (https://github.com/firebase/firebase-js-sdk/blob/master/packages/firestore-types/index.d.ts). All code in the exported classes above should either be part of the public API or prefixed with an underscore. We don't always get this right though - see https://github.com/firebase/firebase-js-sdk/blob/master/packages/firestore/src/api/database.ts#L653. logLevel is not in our types, but can be accessed since it is exported as part of Firestore.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does removing this actually help? It seems like this should have been tree-shaken out?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Tree-Shaking in the browser builds doesn't actually work very well. I am trying to fix that (currently not working though - #2829), but for the "older builds" only excludes code that in modules that aren't loaded at all. Only the ESM2017 build will not include functions, but also only if they are deemed "side-effect free".

Copy link
Contributor Author

@schmidt-sebastian schmidt-sebastian left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your review!

// Escape the promise chain and throw the error globally so that
// e.g. any global crash reporting library detects and reports it.
// (but not for simulated errors in our tests since this breaks mocha)
if (message.indexOf('Firestore Test Simulated Error') < 0) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is special handling of test code that is no longer needed, since we are not using mocha anymore (karma runs our browser tests). So the same test passes now without this special handling.

As for running the unit tests - all tests run as part of CI, and I usually run them locally as well. There are some tests that are "harder" to run locally, such as the minified integration tests (see /integration/firestore), but even those are run in CI.

* always terminated with a separator, and so a successor can always be
* cheaply computed by incrementing the last character of the path.
*/
export function prefixSuccessor(
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general, if code is not in the api/ folder, it can't be used by our users.

In more technical terms, only code that is exported from our index.ts files is considered part of the public API:
https://github.com/firebase/firebase-js-sdk/blob/master/packages/firestore/register-module.ts

Furthermore, the files under /api should match our types (https://github.com/firebase/firebase-js-sdk/blob/master/packages/firestore-types/index.d.ts). All code in the exported classes above should either be part of the public API or prefixed with an underscore. We don't always get this right though - see https://github.com/firebase/firebase-js-sdk/blob/master/packages/firestore/src/api/database.ts#L653. logLevel is not in our types, but can be accessed since it is exported as part of Firestore.

@schmidt-sebastian
Copy link
Contributor Author

@wilhuff for approval.

* always terminated with a separator, and so a successor can always be
* cheaply computed by incrementing the last character of the path.
*/
export function prefixSuccessor(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does removing this actually help? It seems like this should have been tree-shaken out?

@@ -118,18 +118,4 @@ export class TargetData {
this.resumeToken
);
}

isEqual(other: TargetData): boolean {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't isEqual used indirectly by our custom deep equal mechanism?

I worry that we may have tests that are checking that something is not equal that are now accidentally passing while checking reference equality.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TargetData was never passed to our custom "equals" implementation. I actually looked back at the usage and since there is only one call, I decided to inline it. So now we have no code that treats objects with isEqual and without in the same codepath.

Copy link
Contributor

@wilhuff wilhuff left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@wilhuff wilhuff assigned schmidt-sebastian and unassigned wilhuff Mar 31, 2020
@schmidt-sebastian schmidt-sebastian merged commit e4b610d into master Mar 31, 2020
@schmidt-sebastian schmidt-sebastian deleted the mrschmidt/byebyes branch April 6, 2020 19:26
@firebase firebase locked and limited conversation to collaborators May 1, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants