Skip to content

♻️ Guard dependencies in src/{context,core,preact}#33016

Merged
rcebulko merged 16 commits intoampproject:masterfrom
rcebulko:core-preact
Mar 4, 2021
Merged

♻️ Guard dependencies in src/{context,core,preact}#33016
rcebulko merged 16 commits intoampproject:masterfrom
rcebulko:core-preact

Conversation

@rcebulko
Copy link
Copy Markdown
Contributor

@rcebulko rcebulko commented Mar 2, 2021

This PR:

  • adds the import/no-restricted-paths eslint rule
    • prohibits src/core from importing outside of itself
    • prohibits src/preact from importing outside of itself, src/core, or src/context
    • prohibits src/context from importing outside of itself or src/core
  • moves several preact-only helper files (src/loading, src/contextprops) into src/preact
  • update all assertion imports in src/preact and src/context to use new helpers

Remaining excluded files generate linter warnings:
image

@rcebulko rcebulko requested a review from jridgewell March 2, 2021 21:19
@amp-owners-bot
Copy link
Copy Markdown

amp-owners-bot bot commented Mar 2, 2021

Hey @jridgewell! These files were changed:

src/core/.eslintrc.js
src/core/contextprops.js
src/core/loading-instructions.js

// Disallow importing AMP dependencies into core
'target': 'src/core',
'from': 'src',
'except': ['./core'],
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Paths for target and from are absolute; paths in except are relative to the from path. Weird, I know.

'error',
{
// Disallow importing dependencies from outside this directory
'patterns': ['..'],
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

This did not work as desired with subfolders

src/.eslintrc.js Outdated
'./context/scheduler.js',
'./context/values.js',
],
'rules': {'import/no-restricted-paths': 1},
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Plan: Warning for now; once exclusions are migrated, everything errors.


import * as Preact from './index';
import {Loading, reducer as loadingReducer} from '../loading';
import {Loading, reducer as loadingReducer} from './loading-instructions';
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

This removes the only restricted dependency, so this file was removed from the allowlist

*/

import {Loading, reducer as loadingReducer} from '../loading';
import {Loading, reducer as loadingReducer} from './loading-instructions';
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

This removes the only restricted dependency, so this file was removed from the allowlist

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Can we instead whitelist src/context and src/contextprops? Or move them to src/pure? They have been intentionally constructed as "pure". There might be some dependencies there now that have crept in, but I do think we can and should be "pure".

import {CanPlay, CanRender, LoadingProp} from '../contextprops';
import {dev} from '../log';
import {CanPlay, CanRender, LoadingProp} from './contextprops';
import {devAssert} from '../core/assert';
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

These removes the only restricted dependencies, so this file was removed from the allowlist.

@@ -14,7 +14,7 @@
* limitations under the License.
*/

import {Loading, reducer as loadingReducer} from '../loading';
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I think these actually belong in src/core? They're meant to be used by both Bento and regular Components?
/cc @dvoytenko

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

AFAICT is file is not imported anywhere else in the repo except the files in this PR

*/

import {Loading, reducer as loadingReducer} from '../loading';
import {Loading, reducer as loadingReducer} from './loading-instructions';
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Can we instead whitelist src/context and src/contextprops? Or move them to src/pure? They have been intentionally constructed as "pure". There might be some dependencies there now that have crept in, but I do think we can and should be "pure".

@rcebulko rcebulko requested a review from dvoytenko March 3, 2021 21:33
@rcebulko rcebulko requested a review from jridgewell March 3, 2021 21:43
);
}
process.exitCode = 1;
process.exitCode = errorCount || !isCiBuild() ? 1 : 0;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Can you explain this change?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Errors should always fail the build
Warnings (such as for the allowlisted imports) should not fail the build on CI
Chatted offline with @rsimha , looping in for approval on this file

Copy link
Copy Markdown
Contributor

@rsimha rsimha Mar 4, 2021

Choose a reason for hiding this comment

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

I didn't mean for this change to be made to lint.js. We want to continue failing CI builds when there are warnings.

Instead, you can change line 63 in src/.eslintrc.js as follows:

'rules': {'import/no-restricted-paths': isCiBuild() ? 0 : 1},

This will let you see warnings within src when you're doing local development, but not let those warnings show up during CI. Meanwhile, PRs that introduce unaccounted for warnings in other directories will be flagged during CI.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

That makes sense; will do

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Done! PTAL

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

LGTM.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Necromancing this conversation thread for a moment. With this configuration, branches touching any files with warnings get picked up as build targets, and lint emits warnings which in turn fails the task with a non-zero exit code. This means during local development, amp pr-check gets held up by the warnings and can't be useful on these branches. @rsimha do you have any suggestions to work around this? I'd like warnings to be displayed without failing the whole set of checks if possible. Could warnings not fail lint on non-CI builds? I don't see any lint rules that are warnings currently

@rcebulko rcebulko dismissed dvoytenko’s stale review March 4, 2021 19:17

Addressed comments; approval from Justin

@rcebulko rcebulko merged commit fe5417d into ampproject:master Mar 4, 2021
@rcebulko rcebulko deleted the core-preact branch March 4, 2021 19:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants