Skip to content
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

Add lint rule to prevent server code being imported into client #52447

Merged
merged 6 commits into from
Dec 13, 2019

Conversation

joshdover
Copy link
Contributor

@joshdover joshdover commented Dec 6, 2019

Summary

Fixes #49053

This adds new configurations for the no-restricted-paths eslint rule to prevent:

  • Importing any server-side modules into any modules that are not in a server/ directory.
    • This includes common directories often used by plugins. Necessary to ensure that modules containing shared code do not import anything that should be exclusively used on the server.
    • This helps avoid issues where server code inadvertently ends up in a Webpack bundle that breaks the front-end. When these problems happen it is often hard to understand why, and this rule should help.
  • Importing any code from ui/* or uiExports/* into New Platform plugins.
    • These modules will be deleted in the future and should not be supported in New Platform plugins.

Checklist

Use strikethroughs to remove checklist items you don't feel are applicable to this PR.

For maintainers

@joshdover
Copy link
Contributor Author

Didn't get this rule quite right, but now that I have some failures I can play around with it. Will circle back next week.

@pgayvallet
Copy link
Contributor

Fixes #49053 btw

.eslintrc.js Outdated Show resolved Hide resolved
.eslintrc.js Outdated Show resolved Hide resolved
@joshdover joshdover force-pushed the np/server-client-imports branch 4 times, most recently from 9800f40 to ab87325 Compare December 9, 2019 18:35
@joshdover joshdover added Feature:New Platform release_note:skip Skip the PR/issue when compiling release notes Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc v7.6.0 labels Dec 9, 2019
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-platform (Team:Platform)

@joshdover joshdover marked this pull request as ready for review December 9, 2019 18:38
@joshdover joshdover requested review from a team as code owners December 9, 2019 18:38
@@ -31,7 +31,7 @@ import {
import { AuthenticationResult } from './authentication_result';
import { DeauthenticationResult } from './deauthentication_result';
import { Tokens } from './tokens';
import { SessionInfo } from '../../public/types';
import { SessionInfo } from '../../public';
Copy link
Contributor

Choose a reason for hiding this comment

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

FWIW, I like the changes you made. Did the lint rule require these changes?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes it does. If you don't want this to be part of the public contract, we can move this up into a shared types file that only security can import from.

Copy link
Contributor

Choose a reason for hiding this comment

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

BTW shouldn't we ban public code to be imported from server as well? I'm concern about cases when a plugin accesses browser specific API and can throw on the server side

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm not against that, was just focusing this change on fixing the Webpack bundling problems. It looks like there are more violations of this pattern, let me see about doing that change in a separate PR.

.eslintrc.js Outdated Show resolved Hide resolved
Copy link
Contributor

@smith smith left a comment

Choose a reason for hiding this comment

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

APM stuff looks good!

Copy link
Contributor

@streamich streamich left a comment

Choose a reason for hiding this comment

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

Shall we also add rules that:

  • /src/plugins/*/server/**/* should not be able to import from /src/plugins/*/public/**/*
  • /src/plugins/*/public/**/* should not be able to import from /src/plugins/*/server/**/*
  • /src/plugins/*/common/**/* should not be able to import from server, nor public

@joshdover
Copy link
Contributor Author

Shall we also add rules that:

  • /src/plugins/*/server/**/* should not be able to import from /src/plugins/*/public/**/*

As mentioned above, I will do this in a separate change as there are more things to fix here and this is less urgent.

  • /src/plugins/*/public/**/* should not be able to import from /src/plugins/*/server/**/*
  • /src/plugins/*/common/**/* should not be able to import from server, nor public

Both of these are already covered in this PR. Nothing may import from server that is not also a server directory. This eliminates the immediate problem where Webpack bundles get broken.

@streamich
Copy link
Contributor

I see, thanks, every time I get confused by from and target meaning in that ESLint rule.

@jfsiii
Copy link
Contributor

jfsiii commented Dec 9, 2019

Is this only for NP plugins? It seems useful for many. Anecdotally, I've done this twice in the last few months in an x-pack/legacy plugin and would love some protection from myself :)

Just curious, nothing to hold up this PR.

@joshdover
Copy link
Contributor Author

Added a rule to cover legacy plugins as well. There are a lot more violations here, some of which were trivial to fix, others which are not. For the more complex ones I have added eslint-ignore lines. These should be cleaned up when migrating to the New Platform.

Copy link
Contributor

@mikecote mikecote left a comment

Choose a reason for hiding this comment

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

Stack services changes LGTM 👍 Created #52896 for us to change Task Manager's folder structure.

Copy link
Contributor

@walterra walterra left a comment

Choose a reason for hiding this comment

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

ML changes LGTM

@joshdover joshdover force-pushed the np/server-client-imports branch 2 times, most recently from a5394fc to f25494d Compare December 12, 2019 19:28
Copy link
Contributor

@lizozom lizozom left a comment

Choose a reason for hiding this comment

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

@streamich comments aside, the changes to @elastic/kibana-app-arch files are LGTM

@joshdover
Copy link
Contributor Author

@elasticmachine merge upstream

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

@joshdover joshdover merged commit ec2134d into elastic:master Dec 13, 2019
@joshdover joshdover deleted the np/server-client-imports branch December 13, 2019 18:26
@joshdover
Copy link
Contributor Author

Opened #53021 to track adding a lint rule to forbid importing in the other direction (client code -> server code)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:New Platform release_note:skip Skip the PR/issue when compiling release notes Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc v7.6.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add eslint rule to forbid importing server code from public code